Проект "Свободные голосования"

Предлагаю для поддержки множества протоколов использовать специально написанные модули.
Каждый модуль должен создаваться под конкретный протокол.
Каждый модуль должен экспортировать функции:

ITransportModule* - интерфейс к транспорту, именно благодаря ему будет происходить сокрытие реализации протокола.

Примерный вид конфигурации:


Собственно сейчас я хотел бы обсудить основные протоколы: tcp, udp, sctp и режимы их работы.
Мои предложения:

1. upd/ip
   
   1. broadcast - для теста и отладки.
   2. detect - только обнаружение узлов в подсети
   3. multicast - вспомогательный протокол работы (я на него возлагаю большие надежды)
   4. stun - (rfc5389)
2. tcp/ip
   
   1. listen - основной протокол для работы в Internet.
   2. unicast - основной протокол для работы в Internet (параметры списков будут обсуждаться отдельно, первоначально - явное указание).
3. sctp/ip
   
   1. broadcast
   2. detect
   3. unicast
   4. listen
   5. stun
   6. multicast
   7. возможно более интеллектуальные режимы

В первую очередь, думаю, необходимо реализовать поддержку tcp/ip - обсуждение в отдельной теме.
Замечания и предложения будут вносится в этот пост, комментарии будут удаляться.

_________________
AF4B DFB0 0E41 2F7A 09FD 4971 96F0 B176 EA1C DD85

А есть ли смысл в выделении низкоуровневых протоколов в модули? Их количество меняется сравнительно медленно. Реализация тоже достаточно тривиальна. Вполне можно реализовывать их в основной программе.

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

_________________
Во вселенной нет общества в котором "Vox populi, vox Dei" не переводилось бы "О, Боже, как мы в это вляпались".

Насколько я понимаю, Юрий имеет ввиду использование для связи протоколов разного уровня. Я правильно понял?

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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


Согласен.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Да, хоть почтовыми голубями. Ключевой момент - разделить передачу данных от обработки.

_________________
AF4B DFB0 0E41 2F7A 09FD 4971 96F0 B176 EA1C DD85

На данный момент мне система видится как:
1) Набор транспортных модулей, которые знают как и куда подключаться, как передать данные ("пакеты").
2) Модули "протоколов", в частности протокол "выборов". Эти "протоколы" знают как генерировать "пакеты" и как обрабатывать полученные. Собственно бизнес-логика.
3) "ядро", которое загружает и связывает модули, загружает конфиг, обрабатывает сигналы операционной системы и т.п.

Dim, Андрей, вас устраивает высокоуровневая архитектура?

_________________
AF4B DFB0 0E41 2F7A 09FD 4971 96F0 B176 EA1C DD85

Описанная здесь вами архитектура меня устраивает.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

2 и 3 третий пункты да. Первый сомнителен. В моём видении модулю голосований стоит предоставить более высокоуровневый интерфейс. Скажем прописать метод для рассылки данных на группу машин. А вот как конкретно данные будут распространяться это уже возложить на транспорт. Некоторые ноды доступны в одном сегменте сети и им можно мультикастом разослать получив подтверждения по tcp. Некоторым надо передавать по цепочке используя только tcp. Но это всё не должно волновать модуль голосований. Ему достаточно знать что данные будут доставлены, а как именно не его забота.
Аналогично хранение данных в распределённой сети тоже не должно касаться модуля голосований. Он просто там их сохраняет, а распространение по узлам дело сети. Т.е. транспорта.

_________________
Во вселенной нет общества в котором "Vox populi, vox Dei" не переводилось бы "О, Боже, как мы в это вляпались".

Не совсем понял. А Юрий разве не это предлагает?

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

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

Для ядра тоже в таких модулях смысла нет. Они не абстрагируются и ядру в любом случае с ними работать по разному. Следовательно в ядре в любом случае надо там делать специфичную поддержку. А в таком случае лучше сразу их и имплементировать.

Да и использование плагинов в C++ портабельно весьма относительно.

_________________
Во вселенной нет общества в котором "Vox populi, vox Dei" не переводилось бы "О, Боже, как мы в это вляпались".