Давно хотел создать свой протокол для обмена сообщениями внутри локалок, чтобы не требовалось выделенного сервера или хотя бы не требовалась долгая и тщательная настройка сервера. В инете ничего толкового не нашел, есть пара интересных проектов, но они платные и закрытые.
Вообщем, идея протокола такая — он позволяет строить распределенную децентрализованую сеть обмена сообщениями, предоставляющую различные сервисы. Сеть должна строиться и настраиваться автоматически, при минимальном вмешательстве со стороны пользователя. По техническим причинам, автонастройка допустима только в одном сегменте (256 узлов), но с учетом того, что каждый узел может обслуживать до 2^32 клиентов, это более, чем достаточно.
Некоторые принципы и идеи позаимствованы из FTN (фидонет). Что-то придумано с нуля или по образу и подобию уже существующих систем. Многое предстоит придумать и реализовать, а потом много раз переделывать и дополнять. Не знаю, сколько это займет времени… Но попробовать стОит.
Вот такой текст я разместил на своем сайте год назад. И вот что из этого получилось…
Описание:
Протокол распределенной сети обмена сообщениями (DNMP) позволяет строить распределенные сети обмена информацией, обладающими следующими особенностями:
— В сети два вида участников: клиенты и узлы. Узлы образуют между собой
сеть и предоставляют различные сервисы. Клиенты подключаются к узлам.
— Сеть децентрализована, в ней нет единого центрального узла. Каждый узел сети полностью автономен и независим.
— Автоматическая маршрутизация сообщений между узлами одного сегмента на основании данных о доступности других узлов.
— Сообщения содержат список узлов, через которые они прошли.
— Некоторые виды сообщений должны храниться на конечном узле и могут быть востребованы клиентом этого узла.
— Протокол не привязан к какой-либо аппаратной или программной реализации канала связи. Может использоваться любой способ передачи данных пакетами от 80 байт до 4 Гбайт.
Схема работы:
Сеть состоит из узлов и клиентов. Узлы могут принимать входящие подключения, клиенты не могут. Каждый узел имеет уникальный среди других узлов ИД. Каждый клиент имеет ИД, уникальный среди других клиентов своего аплинка.
При подключении точки к аплинку происходит опознание точки на аплинке.
Неопознанная точка регистрируется, ей присваивается ИД. После опознания происходит обмен известными узлами, обновление таблиц маршрутов.
При отправке сообщения, точка указывает в сообщении свой адрес и адрес получателя. Если это групповое сообщение, то адрес получателя может быть пустым. Принявший сообщение узел проверяет адрес получателя. Если получатель среди известных ему точек, то сообщение передается этой точке. Если нет, то сообщение передается аплинку. Если аплинка нет, то сообщение возвращается с пометкой «получатель недоступен». Если клиент-получатель недоступен, то узел-получатель может хранить сообщение некоторое время и передать его клиенту, когда он станет доступен.
Таблица маршрутизации каждого узла содержит список всех узлов сегмента и их соответствие линкам. Кроме того, есть список пограничных узлов, на которые отправляются сообщения для получателей за пределами сегмента.
Типы сообщений:
Приватные:
Приват (Private) — сообщение, отправляемое на указанный адрес. Может иметь большой размер и содержать присоединенные файлы. Если получатель не подключен, сообщение хранится некоторое время на конечном узле.
Приват-чат (Private chat) — сообщение, отправляемое на указанный адрес. Доставляется в реальном времени, размер одного сообщения ограничен 1 КБайт. После доставки сообщения адресату, конечный узел возвращает служебное сообщение о результате доставки.
Групповые:
Канал (Channel) — Канал имеет название, начинающееся с символа # (решетка) и не содержащее пробелов. Сообщение на канал получают все точки, у которых этот канал в списке активных каналов. Сообщения на канал передаются в реальном времени, размер одного сообщения ограничен 1 КБайт.
Форум (Forum) — Форум имеет название, не содержащее пробелов. Сообщение на форум получают все точки, подписанные на него. Узлы хранят некоторое количество сообщений форумов. Клиенты могут запрашивать у аплинка сообщения за выбранный промежуток времени.
Блог (Blog) — То же, что и форум, но только создатель блога может создавать и редактировать новые темы.
Ограничения:
Для уменьшения лавинообразного трафика, групповые сообщения и эхо-запросы автоматически передаются только внутри одного сегмента. При соединении сегментов маршрутизация сообщений настраивается вручную или полуавтоматически (под контролем администратора узла).
Для упрощения топологии, у узла должен быть одновременно подключен один аплинк. В некоторых случаях допустимо использование подключение к нескольким аплинкам с ручной или полуавтоматической настройкой маршрутизации. Использование нескольких аплинков в пределах одного сегмента очень нежелательно.
Узлы должны соблюдать ограничение на число эхо-запросов в секунду. Нарушители должны блокироваться соседними узлами.
Недоступный узел может храниться в списке известных узлов ограниченое время, по истечении которого информация об узле удаляется и его ИД становится свободным.
Ососбенности:
Пароли не используются. При первом подключении генерируется ключ, и им хешируются авторизационные запросы-ответы. Ключ хранится в паспорте (профиле) пользователя.
Кроме сетевого адреса используются глобальные идентификаторы GUID и имена. По имени или GUID можно получить сетевой адрес клиента, и наоборот. При разборе и передаче сообщений используются только сетевые адреса. GUID, имя, и прочая информация о клиенте используются только как синоним сетевого адреса.
Принятие клиента или узла в сеть выполняется вручную. При этом в паспорте принятого ставится идентификатор принявшего его узла. Внутри сети участники могут переподключаться без ручной авторизации. При переподключении новый узел запрашивает паспорт клиента у его старого узла. Сетевой адрес клиента при этом меняется, а вся прочая информация остается неизменной.
========================================================
Более подробно, с описанием формата сообщений и паспорта в статьях на сайте irchat.ru
Существует действующая реализация протокола в виде программы на Delphi, но она еще сыровата. Планирую сделать из нее DLL для подключения к любой программе, и в первую очередь к моему зрелому проекту RealChat. Разработка движется довольно медленно, рывками, по мере времени и желания. Мне очень интересны ваше мнение, критика, предложения и пожелания.
Если кому интересно совместно поработать — добро пожаловать. Я бы хотел сделать кроссплатформенную версию на Java, но сам я жабу плохо знаю, а Дельфя IMHO лучше подходит для разработки сложных проектов в одиночку.
Вообщем, идея протокола такая — он позволяет строить распределенную децентрализованую сеть обмена сообщениями, предоставляющую различные сервисы. Сеть должна строиться и настраиваться автоматически, при минимальном вмешательстве со стороны пользователя. По техническим причинам, автонастройка допустима только в одном сегменте (256 узлов), но с учетом того, что каждый узел может обслуживать до 2^32 клиентов, это более, чем достаточно.
Некоторые принципы и идеи позаимствованы из FTN (фидонет). Что-то придумано с нуля или по образу и подобию уже существующих систем. Многое предстоит придумать и реализовать, а потом много раз переделывать и дополнять. Не знаю, сколько это займет времени… Но попробовать стОит.
Вот такой текст я разместил на своем сайте год назад. И вот что из этого получилось…
Описание:
Протокол распределенной сети обмена сообщениями (DNMP) позволяет строить распределенные сети обмена информацией, обладающими следующими особенностями:
— В сети два вида участников: клиенты и узлы. Узлы образуют между собой
сеть и предоставляют различные сервисы. Клиенты подключаются к узлам.
— Сеть децентрализована, в ней нет единого центрального узла. Каждый узел сети полностью автономен и независим.
— Автоматическая маршрутизация сообщений между узлами одного сегмента на основании данных о доступности других узлов.
— Сообщения содержат список узлов, через которые они прошли.
— Некоторые виды сообщений должны храниться на конечном узле и могут быть востребованы клиентом этого узла.
— Протокол не привязан к какой-либо аппаратной или программной реализации канала связи. Может использоваться любой способ передачи данных пакетами от 80 байт до 4 Гбайт.
Схема работы:
Сеть состоит из узлов и клиентов. Узлы могут принимать входящие подключения, клиенты не могут. Каждый узел имеет уникальный среди других узлов ИД. Каждый клиент имеет ИД, уникальный среди других клиентов своего аплинка.
При подключении точки к аплинку происходит опознание точки на аплинке.
Неопознанная точка регистрируется, ей присваивается ИД. После опознания происходит обмен известными узлами, обновление таблиц маршрутов.
При отправке сообщения, точка указывает в сообщении свой адрес и адрес получателя. Если это групповое сообщение, то адрес получателя может быть пустым. Принявший сообщение узел проверяет адрес получателя. Если получатель среди известных ему точек, то сообщение передается этой точке. Если нет, то сообщение передается аплинку. Если аплинка нет, то сообщение возвращается с пометкой «получатель недоступен». Если клиент-получатель недоступен, то узел-получатель может хранить сообщение некоторое время и передать его клиенту, когда он станет доступен.
Таблица маршрутизации каждого узла содержит список всех узлов сегмента и их соответствие линкам. Кроме того, есть список пограничных узлов, на которые отправляются сообщения для получателей за пределами сегмента.
Типы сообщений:
Приватные:
Приват (Private) — сообщение, отправляемое на указанный адрес. Может иметь большой размер и содержать присоединенные файлы. Если получатель не подключен, сообщение хранится некоторое время на конечном узле.
Приват-чат (Private chat) — сообщение, отправляемое на указанный адрес. Доставляется в реальном времени, размер одного сообщения ограничен 1 КБайт. После доставки сообщения адресату, конечный узел возвращает служебное сообщение о результате доставки.
Групповые:
Канал (Channel) — Канал имеет название, начинающееся с символа # (решетка) и не содержащее пробелов. Сообщение на канал получают все точки, у которых этот канал в списке активных каналов. Сообщения на канал передаются в реальном времени, размер одного сообщения ограничен 1 КБайт.
Форум (Forum) — Форум имеет название, не содержащее пробелов. Сообщение на форум получают все точки, подписанные на него. Узлы хранят некоторое количество сообщений форумов. Клиенты могут запрашивать у аплинка сообщения за выбранный промежуток времени.
Блог (Blog) — То же, что и форум, но только создатель блога может создавать и редактировать новые темы.
Ограничения:
Для уменьшения лавинообразного трафика, групповые сообщения и эхо-запросы автоматически передаются только внутри одного сегмента. При соединении сегментов маршрутизация сообщений настраивается вручную или полуавтоматически (под контролем администратора узла).
Для упрощения топологии, у узла должен быть одновременно подключен один аплинк. В некоторых случаях допустимо использование подключение к нескольким аплинкам с ручной или полуавтоматической настройкой маршрутизации. Использование нескольких аплинков в пределах одного сегмента очень нежелательно.
Узлы должны соблюдать ограничение на число эхо-запросов в секунду. Нарушители должны блокироваться соседними узлами.
Недоступный узел может храниться в списке известных узлов ограниченое время, по истечении которого информация об узле удаляется и его ИД становится свободным.
Ососбенности:
Пароли не используются. При первом подключении генерируется ключ, и им хешируются авторизационные запросы-ответы. Ключ хранится в паспорте (профиле) пользователя.
Кроме сетевого адреса используются глобальные идентификаторы GUID и имена. По имени или GUID можно получить сетевой адрес клиента, и наоборот. При разборе и передаче сообщений используются только сетевые адреса. GUID, имя, и прочая информация о клиенте используются только как синоним сетевого адреса.
Принятие клиента или узла в сеть выполняется вручную. При этом в паспорте принятого ставится идентификатор принявшего его узла. Внутри сети участники могут переподключаться без ручной авторизации. При переподключении новый узел запрашивает паспорт клиента у его старого узла. Сетевой адрес клиента при этом меняется, а вся прочая информация остается неизменной.
========================================================
Более подробно, с описанием формата сообщений и паспорта в статьях на сайте irchat.ru
Существует действующая реализация протокола в виде программы на Delphi, но она еще сыровата. Планирую сделать из нее DLL для подключения к любой программе, и в первую очередь к моему зрелому проекту RealChat. Разработка движется довольно медленно, рывками, по мере времени и желания. Мне очень интересны ваше мнение, критика, предложения и пожелания.
Если кому интересно совместно поработать — добро пожаловать. Я бы хотел сделать кроссплатформенную версию на Java, но сам я жабу плохо знаю, а Дельфя IMHO лучше подходит для разработки сложных проектов в одиночку.
