Неуверен за правильную формулировку темы, к С++ тоже напрямую не относится, но тем не менее.
Есть набор сетевых приложений, функционирующих на разных узлах сети. Каждое приложение генерирует собственную информацию и обменивается ею с другими с помощью сообщений. При этом:
1. приложение "А" изменяет свое внутреннее состояние (получает от датчика информацию, например).
2. информирует все взаимодействующие приложения ("Б", "В", "Г" и т.д.) об изменении состояния, отсылая им id(?) своего последнего состояния.
3. взаимодействующее приложение "Б", получив сообщение, о том, что состояние приложения "А" изменилось, отсылает в ответ id последнего имеющегося состояния приложения "А".
4. приложение "А" на основе id текущего состояния и id состояния, полученного от приложения "Б", формирует "пакет обновления" и отправляет его приложению "Б".
5. процесс повторяется для всех взаимодействующих предложений.

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

Смысл так усложнять?

Клиенты - "наблюдатели" устанавливают TCP соединение с  сервером (возможно, подписываются на конкретный набор данных). В ответ получают текущие данные. 
Сервер (желательно асинхронно) оповещает всех своих подписчиков каждый раз, когда меняются соответвующие данные. Для этого прекрасно подходит паттерн "Observer" (Наблюдатель).

Если сервер заметил что клиент "отвалился", можно раз в N секунд, в течении некоторого времени пытаться восстановить соединение. 
Клиенту тоже стоит периодически пинговать сервер. У TCP сокета есть опция keep alive, возможно она подойдёт для этих целей.
http://www.rsdn.ru/article/net/keep_alive.xml

Это сообщение отредактировал(а) Леопольд - 21.5.2012, 21:03

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

Keep alive не совсем удобное свойство TCP, насколько помню оно зависит от реализации и им не всегда можно управлять в нужных пределах - помню, еще когда начал изучать TCP у Стивенса прочитал, что использовать это свойство неудобно. С тех пор heartbeating реализую всегда сам.

Не вижу в чём проблема, надёжность обеспечиват пакетная передача и TCP. А если сервер умер, то и оповещать не о ком.
Преждевременная оптимизация зло. KISS наше всё...

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

[mergetime]1337665974[/mergetimeЗначит не подошло... 


Это сообщение отредактировал(а) Леопольд - 22.5.2012, 08:55

Дело в том, что для функционирования системы важны клиенты, сервер сам по себе не нужен. Поэтому если сервер умер, а клиенты живые, но не могут общаться, то система умерла полностью. Если же отказаться от сервера, то система будет жива фактически пока жив последний клиент, примерно в этом смысле я имею в виду. Но насчет KISS вы абсолютно правы, тут я призадумался...


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

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

Добавлено через 5 минут и 24 секунды
а свое состояние может менять только A? если да, то вот вам сервер, к которому все подключаются. если нет, то требуется механизм разрешения конфликтов, когда два процесса изменили состояние одновременно.

У вас сервер только "А", или остальные машины тоже хранять свое состояние, которое тоже нужно синхронизировать?
Если сервер действительно один, то что должны делать клиенты при его отказе? Какой информацией они должны обмениваться?

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

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

Это сообщение отредактировал(а) drug007 - 22.5.2012, 16:52

почитайте как устроены одноранговые сети (P2P), большинство проблем уже имеет неплохие решения

Точно! Спасибо за подсказку.