Я имел в виду сделать специальный класс (в дополнение к SharedVar) - SharedArray. И уже в его интерфейс добавить возможность ресайза.


Угу.


Я пока вижу единственное место, где понадобится синхронизация. Это вычисления, когда переменная (назовем ее A) зависит от другой переменной (B) косвенно, через 2 других переменных (C и D) (все переменные расположены на разных узлах). В таком случае вычисление А должно происходить только тода, когда вычислятся С и D после модификации B

Для реализации этого понадобится граф зависимостей и система слежения за версиями переменных. Граф можно строить динамически, но от пользователя понадобится явное описание зависимости и явная фиксация данных. Например так:

Это просто у нас разный уровень подготовки - вот я и не сообразил  Да, полностью согласен. Еще в этом классе предусмотреть бы sharing стратегию - когда весь массив сразу передается между узлами, а когда только изменения элементов. Хотя это, возможно, преждевременная оптимизация.

Граф зависимости и система слежения очень хорошая идея - защелка мне понравилась. Я думаю, что два этих feature можно рассматривать как промежуточный слой между sharing system и конечным пользователем библиотеки. Т.е. достаточно продумать интерфейс и методологию их применения и можно делать реализацию нижнего уровня с небольшой оглядкой на интерфейс зависимостей и слежения за версиями. Мне еще кажется, что достаточно сделать неявное защелкивание данных - т.е. latch защелкивает данные разных версий, но при расчете использует данные одной версии, которую сама выбирает автоматически и при формировании результата просто присваивает версию, которую использовала при расчетах. Думаю, это покроет большинство областей применения и интерфейс не будет перегруженным.

Зачем писать свой фреймверк, когда можно использовать что-нибудь готовое? Во первых, такие проблемы, как правило решают с помощью БД(как правило, на этом и стоит остановиться). У меня складывается впечатление, что автор просто не дружит с БД, поэтому пытается перенести решение проблемы на знакомую территорию - программирование на с++.

Все высказавшиеся в этом топике слабо представляют себе, что такое распределенная система. Автор даже написал что оставит разработку дискавери сервиса на потом, интерфейсы классов и с++ код, с которым будет работать пользователь конечно же важнее  При этом автор  не задает себе те вопросы, которые в первую очередь должен задать себе разработчик распределенной системы.

• Итак, в какой среде это все должно работать, как осуществляется взаимодействие между узлами? Это все находится в одной сети и все узлы сидят на одном свитче, или это просто LAN одной организации, или это несколько организаций, чьи сети объединены через WAN, или это Ad-hock сеть, в которой узлы могут общаться только со своими непосредственными соседями?
• Как выполняются обновления? Они могут осуществляться на одном выделенном узле, или на любом? Есть ли в системе выделенный узел, с помощью которого можно определять истинность?
• В случае, если обновления могут выполняться на любом узле - что должно происходить в случае конфликта, возможно ли расхождение информации на разных узлах, или информация должна быть целостной всегда, или может быть какое-то время, в течении которого она не будет целостной, но если не будет новых изменений, все согласуется рано или поздно (eventual consistency).
• Механизм concurrency control. Ordering.
• Как обновления должны распространяться в системе, синхронно или асинхронно, или что-то среднее? Latency vs consistency tradeoff.
• Отказы, что делать если нода падает?
• Grooup membership. Динамическое присоединение - отсоединение узлов.

Может что-то еще забыл 

Соответственно, от ответа на первый и второй вопрос, зависят возможные варианты ответов на остальные вопросы.

Очень хорошо, что знающие люди подключаются к обсуждению 


Согласен, но я не знаю таких.



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

Именно поэтому:

Это целенаправленное решение.
И именно поэтому же:

Потому что автор их себе задал. И автор их здесь не поднимает, потому что см. выше - задача разделить эти два уровня. Достичь этого предполагается за счет использования таблиц ключ-значение - они являются теми структурами данных, которые будут мигрировать из одного уровня в другой. За счет этого разработку сетевой подсистемы (а это именно то, что Lazin  имеет в виду можно делать параллельно и независимо. Более того, сетевая часть будет взятая готовая - благо вот там то фреймворков хватает. Поэтому важной задачей стоит создание удобного практичного интерфейса.



Система должна быть устойчива к плохим и неустойчивым каналам связи, в том числе работать на слабом оборудования (пусть и в урезанном варианте). Архитектура приложения не должна иметь какие-либо принципиальные ограничения на среду - в идеале должно работать в любой гетерогенной среде. Конечно, на начальных этапах не все может быть реализовано, но ограничений быть не должно.
Обновления должны осуществляться децентрализованно. В идеале по принципу вирусного заражения. Информация должна быть целостной всегда.
Расхождения могут быть, к сожалению, скорее всего от неверной эксплуатации до злонамеренного вмешательства. Помехи и потери в каналах связи здесь рассматривать не будем - это задача коммуникационного оборудования. Этот вопрос актуальный и сложный - на данный момент он вообще никак не решается (только на уровне систем передачи данных), первоначально скорее всего будет просто обнаруживаться факт расхождения и одна или обе стороны будут просто компроментированы с игнорированием результатов от них до разрешения конфликта на уровне приложения (не фреймворка) - либо автоматический, либо вручную с участием человека
concurrency control. Ordering. Этот вопрос меня сейчас мучает больше всего, мы его, кстати, обсуждали с xvr, я ориентировался на timestamp, но есть некоторые моменты, что этого недостаточно (применительно к конкретной задаче на одном из этапов ее решения)
Обновление асинхронное. 
Если нода падает это проблема администратора этой ноды. Все узлы независимы, падения одного из них не должно сказываться на работоспособности системы. Важна именно система - отдельно сами по себе работающие узлы никакой ценности не представляют. Система дожна быть устойчива к падению узла в том плане, что узлы по мере восстановления должны продолжать работу с момента падения.
Организация групп - осуществляется на двух уровня ниже и выше здесь обсуждаемого - физически группирование осуществляется на уровне сетевой подсистемы, логически - на уровне приложения.
В любом случае, вопросы по сетевой подсистеме меня сейчас интересуют меньше здесь обсуждаемого интерфейса по той причине, что от если такой промежуточный интерфейс окажется нереален, нужно будет связывать между собой логику и сетевую часть, что усложнит задачу и потребует другого подхода. В качестве сетевой части я планирую использовать zeromq и zyre - пробные запуски zeromq показали обнадеживающие результаты. zyre пока не трогал, но еще более многообещающий фреймворк для распределенных приложений.
В целом моя мысль изменить подход к решению задачи - не передавать сериализованное представление объекта, а перевести все данные в программе на уровень таблиц ключ-значение и передавать между узлами уже их - т.е. сетевая подсистема понятия не имеет, что она передает. А программист понятия не имеет как передаются данные, которые он обрабатывает. и только для оптимизации программисту нужно будет знать, как все дело организованно.
Решить многие проблемы, в том числе озвученные выше я планирую за счет того, что каждый узел генерирует уникальные в масштабах всей системы данные - таким образом, ни одному узлу не нужно синхронизировать данные с кем-либо, он только лишь оповещает те узлы, которые подписались на его данные. Даже если такой узел умер, то данные с него, являясь уникальными, могут еще долго жить в системе, более того, возможен вариант, что узел будет восстанавливать свои данные получая их обратно с узлов, ранее подписавшихся на него. Но это все более высокий уровень. До него еще нужно дойти.  Меня интересует именно интерфейс сейчас и его практичность. По банальной причине значительного снижения трудозатрат программиста.

Это сообщение отредактировал(а) drug007 - 19.1.2013, 15:27

Это невозможно. В рамках LAN можно сделать вид, что узлы всегда могут быть связаны с другими узлами (нет network partitioning-а), в рамках WAN так сделать уже не получится, в ad-hock сетях вообще возможно использование только gossip-подобных протоколов, со всеми вытекающими 


Автор, ты не понимаешь проблемы в принципе 
Представим, что у нас есть 3 ноды, А, В и С. В определенный момент времени, каждый из них отправляет сообщение широковещательно, всем нодам, в результате, каждый узел получит 3 сообщения. При этом, порядок получения сообщений не гарантирован, если нода А получила сообщения в порядке (В, А, С), то это вовсе не означает, что другие ноды получили сообщения в том же порядке. Если все эти сообщения содержат информацию о том, что и как должно меняться в памяти узла, то мы в итоге получим разное состояние на разных узлах.
Обычно, когда нужно распределенное общее состояние, применяют специальные алгоритмы (google: atomic broadcast, ZAB, Paxos, vector clock, lamport timestams), которые позволяют получить одинаковый порядок сообщений на разных узлах. Соответственно, если просто кидаться сообщениями, данные будут расходиться.
Есть еще такая вещь, как гарантированная доставка. Твой zmq не гарантирует доставку сообщений, если сообщение потеряется, то считай что данные на разных узлах разошлись.


метки времени не помогут, так как на разных узлах, метки времени могут отличаться (даже с ntp) + время прохождения пакета. Нод А отпавил сообщение ноду В в момент времени t0, нод С тоже отправил сообщение ноду В в момент времени t1, t0 < t1. Нод В получил сообщение t1, изменил свое состояние в ответ на  это сообщение, затем он получил сообщение t0, которое было сгенерировано раньше и при этом конфликтует с сообщением от ноды C.


Опять же, с асинхронным обнвлением возможна только eventual consistency. Т.е. ноды могут содержать у себя устаревшие данные и операции чтения будут возвращать устаревшие данные.


Для того, чтобы сопротивляться f отказам, распределенная система должна состоять из 2*f + 1 узлов. Почему узлы могут считаться независимыми я не понимаю. В чем тогда смысл всего этого?


Вот эту таблицу лучше заменить на БД. Пускай БД занимается отказами и прочими вещами.


Я бы порекомендовал добиться сначала чего-нибудь подобного на уровне простого key-value хранилища. Там столько проблем, о которых ты даже не догадываешься. У тебя сейчас много противоречивых идей, то, что ты описал в последней цитате похоже на gossip, если это так, то обеспечить целостность данных не получится (точнее получится, но только с некоторой, достаточно высокой вероятностью).


фигня какая-то

Вообще я все больше и больше не понимаю - что должно в конце получиться то. Это будет набор объектов, доступных на разных нодах, или что? Какие требования к этим объектам, могут ли они друг на друга ссылаться? Короче, предлагаю не парить мозги себе и окружающим и написать mapping для какой-нибудь NoSQL Key Value БД.

Невозможно что? Построение системы, части которой работают в зависимости от конфигурации и в LAN, и в WAN и в ad-hock сетях? В чем здесь принципиальная проблема такой категоричности?

Нет, Lazin, это ты не понимаешь, что данная проблема решается за счет того, что каждый узел генерирует уникальную информацию и ему не нужно ни с кем ее синхронизировать, он просто оповещает другие узлы об этом. Он же ее и упорядочивает - если данные приходят в разном порядке их легко упорядочить.
Гарантированная доставка в zmq обеспечивается выбор reliable транспорта - не нужно выбирать udp, можно выбрать tcp, т.е. zmq надстройка над транспортом. Вот такую же абстракцию сверху zmq я и хочу создать.

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


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


Здесь я одно время планировал прикрутить berkeleydb или что-то в этом роде - ничего серьезнее не нужно. Привязка к конкретной базе убьет масштабируемость, а логика БД будет просто хранение.


Так я выше уровня простого хранилища даже и планирую подниматься. Для моих задач этого достаточно. gossip меня вполне устроит - система в нормальных условиях должна работать с высокой актуальностью данных, при тяжелых условиях актуальность данных может снижаться, но система должна оставаться работоспособной. Т.е. больше волнует целостность самой системы, чем данных. Недопустимо, чтобы система выдала пользователю сообщение об ошибке и выпала. Чтобы не произошло, система должна быть работоспособной. Аналогия - она не должна быть каменной стеной, которая сопротивляется внешним воздействиям и за ней тихо и спокойно, но когда такую стену ломают за ней сразу начинается бардак. Здесь же нужна система гибкая, которая может прогибаться под внешними воздействиями, но никогда не ломаться и как только воздействие прекратилось она должна восстановиться в изначальном состоянии. Это одна из плюшек системы.

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

Я понимаю, что я действительно не разработчик распределенных систем и мои познания ограничены. Возможно я какие-то понятия путаю, более того, я знаю, что некоторые вопросы, которые у меня возникли я смогли пощупать только на практике - т.е. в реальном приложение и мне придется делать некоторые исследования. Что я, собственно и делаю. Просто у меня есть конкретная задача и я ее решаю. У моего фреймворка есть и будут ограничения. Мне не нужен блэкджек со шлюхами, мне достаточно подкидного дурака. Для дурака мне сейчас нужен интерфейс между программистом и сетевой частью.

Это сообщение отредактировал(а) drug007 - 19.1.2013, 15:28

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


google - time series database

Именно это я в целом и делаю. Только вместо БД беру хэш-таблицу. И теперь хочу продумать интерфейс для маппинга данных в такую таблицу и интерфейс для передачи такой таблицы между узлами. И в этом топике мы как раз обсуждали вот этот самый первый интерфейс - когда программист работает привычным для него образом, но все данные, которыми он манипулирует прозрачно для него отображаются в таблицу ключ-значение. которая в свою очередь прозрачно для программиста расшаривается между узлами. зависимости между узлами определяет администратор приложения.
В целом такая система является более технической, что ли, она не для эксплуатации в банках, это ближе к АСУ ТП. Самый яркий пример - сеть цифровой радиосвязи, в которой используются разнородные средства - КВ,УКВ, тропосферная связь, космическая. Узлы постоянно мониторят прохождение радиоволн, в зависимости от этого выстраивают связь, более того, учитывают время суток, сезон, погоду в районе конкретно радиостанции и т.д. и вот этой информацией они обмениваются. поднимать базу данных stand-alone на каждом узле это нереально. каналы плохие и неустойчивые, информация может теряться, но постоянно должны приниматься меры к ее восстановлению. а задачи такой системы будет именно в организации как можно более качественной связи с минимальным расходом ресурсов - т.е. нагрузка уменьшилась на сеть, система выключает мощные станция и переходит на более дешевые каналы и т.д. Тут не допустимо, чтобы дедлок был какой-то или система сказала, что данные устарели на пять минут и я с ними работать не буду. Т.е. целостность данных тут вообще сложно нарушить с точки зрения предметной области - данные могут устареть, но неверными они не могут быть, т.к. система передачи данных нам гарантирует, что данные либо получены, либо не получены. Возможно это прояснит нюансы.

Добавлено через 10 минут и 21 секунду

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

подсказка интересная, несмотря на простоту, спасибо.
но в данном случае это из пушки по воробьям, отлично, да, но оправдано только на крупных узлах. если уж делать такую БД, то в качестве опции на усмотрение администратора приложения.

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

А зачем такой системе быть распределенной? Возможно ей хватит одной машины для сбора и хранения данных? Во многих современных SCADA системах, timeserices базы данных работают на одном сервере, так как они могут собирать и обрабатывать огромные объемы данных. То, что ты описал, похоже по архитектуре на некоторые современные scada системы, в которых есть сервера телемеханики, которые собирают данные с оборудования и далее, перенаправляют их в дисп. центр, в котором они ложатся в timeseries БД. Сервера телемеханики как правило обрабатывают и агрегируют данные, уменьшая нагрузку на центральный диспетчерский центр.

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

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

чтобы не мучаться, в сеттерах прописывается код, генерирующий, например, событие, по которому происходит отправка данных на другие узлы. Работоспособно, но только до того момента, пока не встает вопрос, а как быть, если в сети появляется новый узел и запрашивает все данные? можно будет "вручную" пробежаться по всем экземплярам и вызвать функцию refreshState() (имя не совсем может подходящее) которая вызывает для всех полей экземпляра код, обеспечивающий отправку данных на другие узлы. Вроде тоже работает. Правда, получается, что мы каждое поле по каждому экземпляру отправляем "единично", хотя отправить пакетом данные было бы более быстрым и простым способом, ну да не будем прежде временно оптимизировать, ибо это зло ;)
А как быть, если узел запрашивает у нас не все данные, а только часть? Отправлять в запросе какие поля и каких объектов ему нужны? А если узел имеет примерно половину данных и запрашивает оставшуюся половину, то может получится немаленький запрос, сопоставимый  по объему ответу плюс сам ответ на него опять будет не оптимальная штучная отправка данных. Либо данные всегда отправлять всем скопом.
Таким образом, мы храним данные, в иерархии классов, как удобно с точки зрения разработки, но это усложняет передачу данных по сети.
Второй вариант - хранить вообще все данные в массиве char[]. Хранить индекс на последний переданный на другие узлы байт и тогда, чтобы запросить данные, узел должен лишь передать диапазон байт, который ему интересен - механиз передачи данных по сети упрощается чрезвычайно. Но хранить все в одном массиве с точки зрения разработки - полная ерунда.
Тут и возникает соблазн, создать промежуточный интерфейс, который бы позволил с одной стороны иметь привычный код, в котором доступ к данным был как привычно, в виде полей класса/структуры, переменных. А с другой стороны, чтобы данные хранились в виде некоторого упорядоченного массива в формате, удобном для передачи данных на другие узлы.
Для этого предполагаю использовать хранение данных в генерализованном типовом виде - стандартной структуры DataChunk, каждая такая структура имеет уникальный идентификатор (типа индекса в массиве), который позволяет ее однозначно идентифицировать. DataChunk хранятся в структуре SharedStorage, которая и является генерализированным аналогом массива, на каждом узле используется в единственном числе, также имеет уникальный номер, который является идентификатором узла. Таким образом, зная номер SharedStorage (узла) и номер DataChunk мы можем уникально идентифицировать любые данные в масштабах всей системы. При обмене данными между узлами в запросе будет необходимо и достаточно указать только номер SharedStorage и диапазон номеров DataChunk. Это с точки зрения "сетевой" части. Что касается "прикладной" части - создаем шаблон SharedValue, который позволяет любой тип обернуть необходимыми сеттерами и геттерами. Которые при доступе/записи к переменной будет вызывать соответствующие функции SharedStorage. Так как обычно переменные группируются по какому-либо признаку, поэтому создаем ValueContainer, чья основная задача - группировать переменные SharedValue. ValueContainer имеет свой тип и свои идентификатор. Тип позволяет его наследнику выделиться среди других наследников с другим типом, а идентификатор позволяет выделиться конкретному экземпляру.
Получается, что любые данные будут храниться в виде пар ключ-значение, где ключ - SharedStorage.id, ValueContainer.type, ValueContainer.id, SharedValue.id, а значение - собственно значение в виде char[]. При этом каждая такая пара ключ-значение хранится в DataChunk также в виде пары ключ-значение, но ключом уже является SharedStorage.id, DataChunk.id, а значением предыдущая пара.
Немного сумбурно мне кажется, но мысль должна быть понятной. 
Самый сильный недостаток - большой расход памяти при работе с маленькими данными, т.к. целых два ключа - один ключ для идентификации внутри SharedStorage, а второй ключ для передачи между узлами. Т.е. если нужно сохранить булевскую переменную, то два ключа будут по размеру во много раз больше, чем само значение. С другой стороны, что сейчас эта память стоит?
Критика приветствуется.

xvr, у меня в качестве ключей long, поэтому 40 байт вышло - тут есть где поиграться, но при 2 байтах на все ключи эта схема не работоспособна

Это сообщение отредактировал(а) drug007 - 23.1.2013, 14:04

Для передачи по сети можно отделить информацию, описывающую структуру данных от самих данных. Т.к. структура у вас в процессе работы не меняется, то ее достаточно передать один раз за сеанс. А вот данные меняются - вот именно их и надо передавать постоянно.
Для того, что бы можно было определить какие данные пришли, нужно к ним прикрепить некий ID, но он не обязан совпадать с набором ValueContainer.type, ValueContainer.id.
В качестве ID можно использовать пару <IP адрес отправителя, порядковый номер данных в ValueContainer на отправителе>. IP вам выдаст сетевой уровень, т.е. с данными нужно передать только индекс в контейнере. Если количество переменных на узле не превышает 65К, то достаточно 2х байт. (Если превышает - то сделать столько байтов, сколько нужно).
Информация о самом ValueContainer (вместе с IP узла, где он находится) передается в процессе network discovery.


Это сообщение отредактировал(а) xvr - 23.1.2013, 15:57

Да, вполне вариант. Просто я решил разбить передачу данных еще на два уровня - первый уровень организация такой сложной структуры данных локально на конкретной машине, второй уровень - оптимальная передача этих данных по сети. На первом уровне я исхожу из того, что смело жертвую объемом памяти для упрощения кода и для скорости. Поэтому структура раздутая, но ее обработка простая - передав на другой узел данные по своей схеме я гарантирую, что получив любой DataChunk любой узел сможет восстановить из него данные с полным извлечением имеющейся информации в этом DataChunk'е - т.е. мне нужно будет каких-либо дополнительных данных типа схемы данных. Схема организации данных прошита жестко в коде, т.е. ее не надо передавать (хотя это гибче, конечно, но я, честно говоря, не ставил задачу организацию взаимодействия с неизвестным узлом). Зная все id по моей схеме из куска сырых данных можно однозначно восстановить данные. Поскольку в общем случае я не могу ориентироваться на IP, я предусмотрел как можно более общую схему, пусть и избыточную. А вот в конкретном случае можно уже сжимать данные в том числе по вашей схеме. А если связь будет точка-точка то вообще адрес не нужен.
Хотя здесь есть нюанс - у узла У1 могут быть данные узла У2, и У3 может потребовать эти данные у У1 (например У2 упал как раз в этот момент) - тут уже по сетевому адресу нельзя будет идентифицировать, так как передающий узел будет У1. Поэтому я думаю будет гибко сделать пусть раздутую, но гибкую структуру в памяти, а при передаче уже изменять структуру данных ну и банальное сжатие никто не отменял.

По моему это перебор. Раздавать данные должен тот, кто их производит. Использование левых узлов в качестве запасного кэша данных сильно усложнит организацию системы.

Похоже подошла очередь обсуждения сетевого уровня   Для начала огласите требования, что требуется от сети узлов?