Соль в том, что использование пар ключ-значение упрощает реализацию данного подхода - в самом общем случае можно передавать между узлами все данные - они либо будут дополнять друг друга, либо дублировать. И абсолютно никакого конфликта.



К сожалению четкими и конкретными требованиями похвастаться не могу, так как проект исследовательский да и учебный, прямо скажем. Нужно уделить этому время, которого пока нет. А вот на уровне пожеланий - сказать могу сейчас  Сеть не должна быть привязана к конкретному транспортному протоколу. Каждый узел имеет конфигурационный файл, где прописаны взаимодействующие узлы, но сеть должна быть автоматически реконфигурируемой с целью (нечастого) изменения топологии сети и появления новых узлов. Сеть должна быть не чувствительна к порядку появления узлов в сети. Устойчива при постоянном появлении и выпадении узлов. Уметь игнорировать узлы при необходимости. 
Лучше, конечно, это все продумать в виде четких лозунгов. А то поток сознания некий, но пока что есть то есть.

Возможна сильная перегрузка сети ненужными данными. Особенно при большом количестве узлов.


Эээ, это как бы взаимоисключающие пункты   

При таком подходе "в лоб" так и будет, однозначно. Но ничто не мешает позднее добавить дополнительную логику для исключения подобных вариантов. Т.е. первоначально все узлы обладают равными правами и получают одну и ту же информацию, впоследствии у каждого узла добавятся особенности и он будет потреблять и производить информацию разных типов. Мое мнение, что если первоначально реализовать возможность передачи всех данных легче потом добавить ограничение, чем изначально для каждого рода информации прописывать свой dataflow. Кстати, фактически я пытаюсь сделать dataflow платформу на самом деле, если вдуматься...

Согласен, я и говорю - поток сознания, а не четкая формулировка.  Я имел в виду, что узел при запуске получает подготовленные данные с кем и как ему работать, но впоследствии будет нужно разработать вариант динамической конфигурации. Т.е. это не одновременно должно быть, а движение от простого к сложному.

Ровно наоборот. Введение конфигурации dataflow возможно потребует полной переделки системы комуникации между узлами. Да и в зависимости от степени связанности узлов оптимальные методы коммуникации могут сильно отличаться

Согласен, конечно. Но разве нельзя разделить их, decoupling вещь хорошая же - в начале простую систему где все расшаривается между всеми, а потом уже усложнить. Переделывать простую систему и не жалко. Плюс совместить с итерационной разработкой. Сразу задание на такую систему сделать это нереально. А разбить на этапы и помаленьку уточнять по мере эволюции? Это классно иметь сразу ТЗ, но это не всегда возможно. Я бы сейчас хотел отработать код для взаимодействия распределенной системы без привязки к коммуникационной среде. Саму логику такого взаимодействия, его достоинства и недостатки (помимо расхода памяти  ).

Это будет не переделка, а создание ее заново.   


Некоторые 'уточнения' могут оказаться в корне не совместимы с тем, что уже сделано   


Но хоть что то иметь надо, нельзя же изобретать систему по мере ее написания   


Сначала определитесь с алгоритмами этой самой 'взаимодействия распределенной системы'. 

Для начала - в системе будет выделенный (или не выделенный) сервер, или она будет вся однородная?
Узлы будут обмениваться данными напрямую или через сервер?

Сеть однородная
Обмен напрямую
Если честно, я планирую использовать zmq в качестве сетевой платформы. Там есть такой паттерн как Clone - CloneServerи CloneClient. Они практически реализуют половину нужной мне логики, сервер расшаривает между клиентами таблицу пар ключ-значение. Я по простоте душевной предполагаю потом расширить этот паттерн и на каждом узле создавать такой сервер и клиент с целью реализации одноранговой сети. Отсюда исхожу, что нужно продумать интерфейс между приложением и таблицей ключ-значение.
zmq вещь интересная, не реклама, но посмотрите код распределенного чата Я человек неискушенный, меня впечатлило.

Откуда взялся сервер в однородной сети? Или у вас все узлы будут серверами?   


Ага, но это уже не Clone паттерн - он предполагает 1 источник данных, который будет рассылаться на все клиенты. Кто будет этим 1 источником?

И вообще, насколько я понял ZMQ это весьма навороченный транспортный уровень, т.е. с точки зрения топологии сети он недалеко ушел от чистого TCP/IP (его внутренние вкусности пока оставим за бортом - на сеть они не влияют)

Поэтому вопрос остается - как будет производится построение сети из ваших узлов? Будет ли какая то точка привязки (например имя хоста, которое будет определять сеть), или все будет производится абсолютно динамически и без какой либо конфигурации? Если второе, то как будет определяться та часть сети, где узлы будут искать друг друга?

PS. Сделать сеть совсем однородную (без какой либо разновидности сервера, пусть даже динамического) очень и очень проблематично, а уж сделать эффективно скорее всего вообще невозможно.

однородная в смысле, что не будет выделенных сервера и клиентов - будет одно приложение. а внутри него будет сервер и клиент.


вот каждый узел и будет тем самым единственным - они же все уникальны у меня


Первоначально у каждого узла будет конфигурационный файл, в котором прописаны нужные ему узлы - те узлы, к которым он подключается как клиент. А другие узлы, у которых в конфиге прописан  он, будет к нему как клиенты подключаться и он для них уже будет сервером - такое просто решение "в лоб". Потом уже желательна динамическая конфигурация, но это отдаленное будущее - главное вообще предусмотреть такую возможность.

Ибо я согласен, что 

Да я и не знаю транспорта, который бы позволил обойтись без сервера. Разве что-то вроде RS-232 

'Каждый' не может быть 'единственным'. Для Clone патерна серверный узел должен быть ровно в 1 экземпляре. Или придется делать N штук Clone'ов, но это совсем чехол - у вас на каждом узле будут жить сервера по количеству узлов в сети, этакий multi сервер   


Это тупиковый путь, при малейшем изменении сети вам придется переписать конфиги на всех узлах, причем переписать вручную   Узел вообще не должен знать кто у него источник данных, он должен оперировать только именем переменной, которая ему нужна.


При таком подходе у вас в качестве сервера выступают конфиг файлы.

Некоторое пояснение - под сервером я имел в виду узел, который хранит конфигурацию сети. Непосредственно данные передаются узлами непосредственно друг другу. Так что никакого постоянного взаимодействия узлов с сервером не происходит, и делать для него клоны явно нерентабельно.

При статической конфигурации сети всем узлам достаточно знать IP сервера, собственно он и будет определять узлы, из которых состоит сеть.

В случае динамической конфигурации сервером становится первый стартовавший узел, но понадобится дополнительные заточки в протоколе о том, как этот сервер будут находить другие узлы (например через broadcast в пределах сегмента сети), как выбирать сервер, если несколько узлов поднялись одновременно и как передавать функции сервера, если текущий сервер отключился от сети (например упал)

Именно так - на каждом узле будет серверная часть - серверная в том плане, что к ней подключаются.


Это же на начальном этапе. Иначе можно застрять на этапе discovery service - поэтому в начале все-таки бизнес-логика, а уже потом удобства. К тому же зачем переписывать на всех узлах? Если узлу А больше не надо получать данные с узла В, но нужно с узла С - то меняется конфиг только на узле А - из него убирается В и добавляется С. Конечно это все упрощенно, но нет речи о законченной системе для полета на Марс. Главное, чтобы принципиальных ограничений не было. Поэтому вполне можно оставить так для начала:


По идее получается, что типичная сеть сервер-клиенты многократно накладывается на саму себя (с изменением сервера каждый раз) по количеству узлов в сети и получается аналог одноранговой сети. Или я где-то сильно ошибаюсь?

Что у вас первично - имя разделяемой переменной или узел, на котором она генерируется?

Они неразрывны, единое целое. Так как каждый узел генерирует уникальную информацию. Она может пересекаться с другими узлами по смыслу и содержанию, но все равно считается уникальной - например, если два датчика температуры измеряют температуру в одном и том же месте (неважно по какой причине, к примеру) то несмотря на то, что это температура по сути одна и та же, но информация с этих датчиков будет уникальной - будет включать в себя не только номер датчика, но и номер узла. Проблема отождествления информации с разных узлов ложится на приложение. Т.о. я планирую избавить приложение от нужды организовывать взаимодействие на низком уровне с другими узлами. А для отождествления что данная информация дублируется несколькими узлами у него уже будут все необходимые данные - и оно может, например, отказаться от получения данных с определенного узла.

Т.е. идентификатор узла по сути входит в имя переменной. Тогда действительно координирующий сервер не нужен, но нужна какая то система сопоставления экспортируемых и импортируемых переменных. Это могут быть и конфиг файлы на каждом узле, но может быть и нечто иное - это сильно зависит от планируемого способа использования этой системы.


Это и не надо, фреймворк это должен реализовывать в любом случае. 

Вариант с конфиг файлами может не подойти например в таком случае -

• Есть узел А, и на нем переменная B, и все другие узлы ее используют.
• Теперь либо имя узла меняется на C, либо имя переменной на нем на D - все узлы в сети должны будут обновить свои конфиги  

я планирую (опять же в начале) просто выставлять на экспорт все переменные с возможностью ограничения в дальнейшем. Потому что я опять же считаю, что выстроить обмен данными главнее, а уже потом можно этот обмен ограничивать. Потому что это большой объем работы - подобные ограничения, я думаю, ближе должны быть к уровню приложения, и в нем уже пользователь будет определять, что он хочет экспортировать, а что нет. А во фреймворке нужно будет предусмотреть средства для подобного регулирования. Но я даже пока не знаю, когда дойду до этого. 



Да, должны будут. А куда деваться? Динамическая реконфигурация вещь хорошая, конечно, но тоже в перспективе - ее создание усугубляет тот факт, что система становится слишком уязвимой к внешним воздействиям, в том числе злонамеренного характера. Вот как бы такая гибкость не вылезла боком-то в этом плане...