Distributed Network Messaging Protocol — хорошо забытый FTN

    Жила-была технология FTN aka FidoNet. Она и сейчас живет где-то на пыльных системниках, но когда интернеты в России были маленькими, это была весьма популярная технология обмена сообщениями.

    Короче говоря, я решил скрестить технологии FTN и IRC, но при этом автоматизировать все возможные настройки, сведя участие рядового пользователя к указанию стартового узла для подключения, а оператора узла к подтверждению приема подключившегося в сеть. Все остальное делает компьютер. При этом никаких паролей, никаких таблиц маршрутизации, списков узлов и прочего гимора. Вернее, можно и вручную настроить, но не обязательно.

    Схема сети



    Для этого пришлось придумать новый протокол обмена сообщениями в распределенной сети — DNMP, который позволяет строить распределенные сети обмена информацией, обладающими следующими особенностями:

    — В сети два вида участников: клиенты и узлы. Узлы образуют между собой сеть и предоставляют различные сервисы. Клиенты подключаются к узлам.

    — Сеть децентрализована, в ней нет единого центрального узла. Каждый узел сети полностью автономен и независим.

    — Автоматическая маршрутизация сообщений между узлами одного сегмента на основании данных о доступности других узлов.

    — Сообщения содержат список узлов, через которые они прошли.

    — Некоторые виды сообщений должны храниться на конечном узле и могут быть востребованы клиентом этого узла.

    — Протокол не привязан к какой-либо аппаратной или программной реализации канала связи. Может использоваться любой способ передачи данных пакетами от 80 байт до 4Гбайт.

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

    Схема сетевого пакета

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

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

    Все это на сегодняшний день хорошо документировано и реализовано в виде «испытательного стенда». По сути, реализованный функционал аналогичен протоколу Jabber, но при этом на порядок более экономичен по траффику и эффективен при маршрутизации и парсинге. А функционал сетевой подсистемы близок к Skype.

    Аббревиатура DNMP трудна для запоминания и произношения, поэтому технология получила название Talaria — это такие крылатые сандалии у древнегреческих богов.

    До этого было рабочее название Grouper (Групер, Каменный окунь). Grouper — оно как бы символизирует. Кроме того, каменный окунь может быть гермафродитом, что схоже с идеологией совмещенного клиента и сервера. И вообще, прикольная рыба. Но, оказалось, что это название уже используется другими сетевыми проектами. Поэтому технология переименована в Talaria, а испытательный стенд я не стал переименовывать.

    Но это еще не все! Есть документированные, но еще не реализованные возможности:

    Внутри сети у клиента имеется паспорт — набор сведений клиента, который мигрирует между узлами, если клиент подключается к другому узлу. Паспорт содержит как основные сведения о клиенте (адрес, GUID, имя), так и дополнительные (произвольная информация, список контактов, подписки на сервисы, неполученые сообщения.

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

    Коммерческая версия протокола с улучшенной защитой, включает в себя:
    — Защищенный вариант сетевого пакета — с расширенным таймштампом, контрольной суммой, цифровой подписью, сжатием и шифрованием содержимого, подтверждением доставки.
    — Более строгая валидация узлов и точек, отдельные наборы ключей для каждой пары узлов, централизованное управление сетью.

    Документация по проекту (CHM):
    irchat.ru/page.php?id=105&a=dl

    Исходники на трекере проекта:
    svn.irchat.ru/browser/trunk/Grouper

    Проект разрабатывается на Delphi 7 с использованием мультиплатформенных библиотек и компонентов, может быть легко перенесен в Lasarus/FreePascal. Можно и на C/C++ переписать, но я буду очень скучать без VCL.

    Любопытные могут скачать работающую тестовую версию из папки с исходниками и поэкспериментировать. Вот какие файлы нужны:

    *.exe - точка (клиент), узел (сервер), монитор
    *.bat - для запуска с разными настройками
    /data/*.* - папка с настройками
    

    Небольшая инструкция по пользованию Grouper:
    irchat.ru/forums.php?m=posts&q=77
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 75

    • НЛО прилетело и опубликовало эту надпись здесь
        0
        Тоже сразу про XMPP aka jabber вспомнил. Хотел автора поздравить с изобретением оного, но опередили :D
          0
          Скорее, вопрос в том, почему бы не сделать надстройку над джаббером, а не над irc.
            0
            Сравните форматы сообщения Jabber и Talaria.
          0
          Почему у вас ни слова про OSPF, ни даже про занюханный RIP?
            –1
            На данный момент предусмотрено автоматическое выстраивание сети в виде дерева, а там несколько проще с маршрутизацией. Просто таблица даунлинков, а все остальное идет на аплинк. Для сетей в сотню узлов вполне достаточно, IMHO.

            Когда будет стабильно работать упрощенный вариант топологии, тогда можно будет экспериментировать с более сложной топологией и более хитрой авто-маршрутизацией, учитывающей проходимость в оба конца линка, множественные каналы, итд…
              0
              Дерево? Я правильно понимаю, что для того, чтобы всё это поломать достаточно сломать корневой узел?
                0
                Линки сломанного узла подключатся к другому узлу. Смотрите схему.
                  0
                  Если «подключатся к другому узлу», то это уже не дерево, а граф. Для этого не нужно ничего рисовать, чистая математика.
                    0
                    Если не более одного аплинка, то по-любому дерево получается.
                      0
                      т.е. не существует узлов с двумя «аплинками»? и в худшем случае пакет в сети из n узлов проходит n-1 ребро?
                      масштабируемо однако.
                        –1
                        Предусмотрена возможность настроить аплинков и роутинг на них вручную.

                        Если я начну сразу делать самонастраиваемый граф на 100500 узлов, то скорее всего, ничего хорошего не выйдет. Сколько человеко-часов (вернее, человеко-лет) ушло у DARPA и прочих разработчиков действующих сетей? Да и то, начинали с простых вещей — RIP и тому подобного.

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

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

                          в любом случае проект классный, плюсик поставил.
                        0
                        Если аплинк один «в принципе», то когда он дохнет, вся ветка дерева дохнет.

                        Если есть резервные аплинки, то это уже не дерево, а граф, в котором есть активные и пассивные грани.

                        Поверьте мне, этот вопрос много и серьёзно прорабатывали до вас — потому я и написал «почему ни слова про ospf?»
                          –1
                          Представьте, что Талария это ad-hoc IP сеть, в которой только UDP-пакеты с подтверждением о доставке (без сеансового уровня). Ничего там не сдохнет, просто маршруты по умолчанию перестроятся и пакеты побегут по новому маршруту. На уровне приложений вообще ничего не произойдет.
                            0
                            Когда вы говорите «пакеты побегут», у меня возникает ощущение, что вы говорите не об ИП-сетях. Напоминаю, что в IP-сетях используется однохоповая маршрутизация (маршрутизатор ничего не знает о полном маршруте, и только перекладывает пакеты слева на право согласно своим табличкам).

                            И каким же образом вы собираетесь исключать циклы? Узел А отдаёт пакет узлу Б, узел Б узлу С, узел С узлу Д, а тот отдаёт его обратно А.
                              –1
                              Сообщения содержат список узлов, через которые они прошли.
                                0
                                Ага, то есть мы отказываемся от stateless маршрутизации и начинаем себя искать в пути. В этом случае аналогии с IP крайне ошибочны, правильнее говорить «подобные электронной почте».

                                В этом случае возникает другой вопрос: а почему обязательно использовать единственный маршрут? Что мешает отправлять сообщения разными путями, балансируя нагрузку?
                                  –1
                                  Совершенно верно, это скорее почтовая сеть. Со всеми плюсами и минусами.

                                  Единственный маршрут прост в реализации. В дальнейшем попробую реализовать Дейкстру с учетом цены пути. Главное, чтобы он был достаточно простым в реализации и не требовал много ресурсов.

                                  Вопрос в том, как скоро это понадобится. Талария использует двухуровнувую маршрутизацию, поэтому огромное число абонентов можно держать в сети из всего лишь десятка узлов. Думаю, между десятком узлов с маршрутизацией особых проблем не будет.
                                    0
                                    Никогда не рассчитывайте, что 4 миллиардов адресов хватит надолго (С) ipv4.

                                    Если по сути — зачем изобретать сохранение пути, если можно использовать stateless маршрутизацию и отдельный протокол, собственно, маршрутизации?

                                    Обратите внимание, что сам протокол (тот же OSPF) позволяет автоматически прокладывать путь, даже если произошёл сложный обрыв.

                                    Представьте себе такую схему:

                                    +---------------------C---G---H--I---+
                                    |     +----D-----+                   |
                                    |     |    |     |                   |
                                    A-----B----E-----F-------------------J
                                    


                                    Вам нужно передать сообщение от A к J. Ближайший маршрут — через B-E-F или через B-D-F

                                    Сообщение дошло до B, в этот момент F упал. Сообщение идёт до E, оттуда до D, возвращается к B, обнаружен цикл, сообщение не доставлено. Хотя можно было бы это пустить через C и далее.

                                    Таких циклов можно много наворотить. Как решать будете?
                                      –1
                                      IPv4 еще дышит (и будет еще дышать) благодаря NAT. Без него адреса уже давно бы кончились. А если сделать аналог NAT в Таларии, то трудно представить, сколько абонентов сможет обслужить такая сеть.

                                      Вы нарисовали граф, а я ориентировался на дерево. Впрочем, вполне возможно, что описанная ситуация случится и в дереве. Если сообщение зашло в тупик, то придется анализировать пройденный путь и выбирать другой маршрут. Или тупо убить сообщение, как это делается в IP при истекании TTL.
                                        +1
                                        Отсюда мы идём к простой мысли: оставьте транспортный протокол транспорту, сетевой — сетевому. Пишите прикладной протокол — вот и ладушки. Не надо пытаться изобретать маршрутизацию.
                                          –1
                                          И встать в конец шеренги IP-based технологий, мужественно преодолевая недостатки и ограничениям несущей сети? Неинтересно.
                                  –1
                                  … И опять же, это не дерево, а построение пути в графе с использованием стека.
                      +2
                      Не похоже это на дерево, циклы-то должны иметься, хотя бы для резервирования.
                  0
                  Что-то мне подсказывает, что в ближайшее время появятся несколько хороших, но несовместимых IM-протоколов.
                    –6
                    Delphi… *поблевал*
                      +1
                      totalcmd до сих пор пишется на Delphi 2(!) и отлично работает во всех виндах от 95й до семерки. быстро и без глюков. Важен не инструмент, а то как его применяют
                        0
                        уже не 2. и автор уже планирует переход на FPC/Lazarus
                          0
                          для 32битных версий автор использует делфи 2, а вот 64битную пока делает на лазарусе.
                      +2
                      FTN, конечно, была интересной сетью…

                      Если уж делать такой проект, то кроссплатформенным. Одни из самых востребованных клиентов — для смартфонов, как с этим у дельфи? Идея интересная, наличие документации и реализации, это огромный плюс. «Коммерческая версия протокола» — удивляет. Как протокол может быть коммерческим?
                        +3
                        Чтобы придумать и испытать новый протокол, нужен максимально удобный инструмент. Дельфи (а точнее, ее IDE, библиотеки классов и компонентов) лучше всего подходит для работы над сложными вещами в одиночку, экономит кучу времени. Результатом работы будет общедоступное описание протокола, который можно реализовать на чем угодно и кем угодно.

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

                          –2
                          уж C# хотя бы или java.
                          Но никак не труп, как бы печально это не было.
                            +2
                            Ой, Тотал Коммандер написан на Дельфи…
                            Да и вы таки не поверите, сколько ещё всего вокруг вас ;)
                              +2
                              Тотал Коммандер был начат на Дельфи, когда Дельфи еще в соку было. не переписывать же им его. поэтому TC совершенно не показатель. вы лучше приведите примеры новых программ, написаных на Дельфи.
                              (Сам в свое время перешел на .net с Дельфи, потому что от Дельфи начало попахивать мертвечинкой)
                                +1
                                qip на делфи. и до того как его купили был очень даже стабилен и шустр, сейчас согласен он медленно катится к состоянию клиента аси.
                                  0
                                  Список программ можете посмотреть здесь
                                  ru.wikipedia.org/wiki/Delphi_(язык_программирования)
                                  Заодно и узнаете, что среда может генерировать и .NET код.
                                  0
                                  Примерно нуль, т. к. дельфи windows only, на lazareus пожалуй знаю только PeaZip, а на Kylix только TuxCmd.

                                  Если не ошибаюсь, биндинги к lazareus'овским библиотекам не слишком тривиальны и могут требовать специфичные runtime компоненты, соответственно можно забыть о включение в purple/telepathy.
                              +3
                              спросите у Skype
                              +2
                              Где векторы? Где гипертекст, я вас спрашиваю?
                                +1
                                И поддержка буквы Ё.
                                +3
                                статья интересная, и картинки такие красивые. но хочется задать стандартный вопрос:
                                какие актуальные задачи решает данный протокол?
                                я пока не понял.
                                  +1
                                  обучение и развитие еще одного хорошего отечественного разработчика =)

                                  это видимо как у веб-программистов: пока свою цмс не напишут — не успокоятся и не начнут заниматься чем-то серьезным.
                                    +2
                                    вот и мне так кажется. статья интересная, но хочется, чтобы разработчик правильно позиционировал свою разработку.
                                      0
                                      почему же? амбиции, основанные на какой-либо работе, разработчиков довольно часто полезны.
                                      0
                                      а вот по-моему в подчеркнутом вами случае велосипедостроение очень очень много пользы приносит — например неплохое владение языком и технологиями + понятие устройства CMS, так что с реальными потом легче становится работать. Хотя ничего не могу утверждать, ибо веб-разработка не есть суть моих занятий, так сталкивался иногда по воле судьбы(а точнее острой нехватки денег), хотя до сих пор теплится надежда, что время найдется и я снова этим займусь. ой, господи, понесло меня что-то после пива) вобщем ИМХО)
                                        0
                                        По идее точно так же можно набираться опыта, изучая сторонние CMS.

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

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

                                      Еще мне по работе нужна была сеть обмена данными с филиалами. Тогда (года 3 назад) с интернетами был напряг, и единственным надежным способом передачи данных в автономном режиме был фидошный софт. Но его настраивать — тоже дело весьма непростое. Удаленно настроить (общаясь по телефону с женщиной-оператором ПЭВМ) было практически нереально.

                                      Сейчас же можно использовать Таларию как основу сети мобильных устройств ограниченного радиуса действия. Или как подпольную неконтролируемую сеть, способную работать в условиях постоянных обрывов связи и изменения состава участников. Или просто для чата в городской локалке.
                                        +1
                                        IRC тоже не самое свежее что есть в мире.

                                        По поводу мобильных устройств есть Zigbee, который все это уже умеет. По поводу подпольного интернета, то он тоже уже есть! называется I2P.

                                        Да и кстати на каком уровне сетевого стека должна жить Талария? Она поверх TCP/IP или ниже?
                                          0
                                          Да и кстати на каком уровне сетевого стека должна жить Талария? Она поверх TCP/IP или ниже?
                                          Она вообще отдельно, ей не нужен носитель. Хоть поверх голубиной почты. =)
                                            0
                                            А в прототипе что используется? UDP?
                                              0
                                              ТСР для имитации линков и DDE для мониторинга.
                                                0
                                                DDE? ну вот этого не надо, пожалуйста.
                                                  0
                                                  Предложите что-то лучше для мониторинга десятков запущенных локально копий приложения. Сейчас это сделано буквально тремя строками кода, и работает именно так, как надо.
                                                    0
                                                    сокет/пайп?
                                                      0
                                                      Сокеты сложны и капризны, даже UDP сокет сложнее, чем DDE. Пайпы не разделяются копиями приложения, вторая копия уже не сможет работать с пайпом, который занят первой копией.
                                                        0
                                                        Неправда Ваша. Во-первых, сокеты просты как грабли, особенно UDP. Во-вторых, сокеты несомненно проще чем любой DDE, даже DDEML, не говоря уже о родном DDE API. В-третьих, в VCL/LCL, насколько я помню, есть очень замечательные обёртки, которые делают программирование сокетов просто сказкой (хотя, до, например, тиклевых и перловых обёрток им далеко).
                                                          0
                                                          Для сокетов нужно писать обработку ошибок, а для серверных еще и обработку и синхронизацию потоков — современные обертки (Indy, Synapse) принимают входящие пакеты в отдельных потоках, даже для UDP.

                                                          В DDE все гораздо проще. Есть текст (набор строк), который расшарен между приложениями. Если кто-то его меняет, то у других срабатывает Event, что текст изменился. Все!

                                                          Или можно тупо отправить клиентом на сервер текстовое сообщение dde.PokeData('Bla-bla-bla') — никаких коннектов, хостов, таймаутов, и прочей херни. Сервер тоже может сделать то же самое, тогда сообщение получат разом все клиенты.

                                                          То, что DDE очень старая технология (еще со времен Windows 2.0) — не значит, что она плохая.
                                                            0
                                                            Так, смотрим в man send (2):
                                                            ssize_t sendmsg(int sockfd, const struct msghdr *msg, int flags);

                                                            Казалось бы, что проще? Никаких коннектов, таймаутов и так далее.

                                                            И я не вижу, где в DDE хоть что-либо проще. DDE — типичный пример over-engineered technology. И таки да, DDE — ужасная технология. Как, впрочем и OLE/COM.

                                                            P.S. Да, я понимаю, что с точки зрения TDDEClient.Create эта технология кажется действительно очень простой, но, поверьте, зная, что у неё в потрохах (да, я видел DDEML и то, что было до него), сказать, что DDE прост, язык не поворачивается.

                                                            P.P.S. А вообще, завязываться на архаичную непортируемую технологию крайне неразумно.
                                                              0
                                                              Напоминаю, что DDE используется для мониторинга состояния множества запущенных локально копий «испытательного стенда». И прекрасно с этим справляется.

                                                              В «продакшене» будут другие, платформенно-независимые технологии мониторинга, скорее всего в виде syslog + веб-интерфейса + telnet.
                                      0
                                      > Можно и на C/C++ переписать, но я буду очень скучать без VCL.

                                      Я так понимаю, на безиксовой машинке клиент не запустишь. Рекомендую хотя бы функциональность как-нибудь отделить от гуя и переписать на С.
                                        0
                                        Нагуя нам без гуя, когда с гуем догуя? =)

                                        Если кто-нибудь клиента на ncurses напишет, я не против. А базовый функционал по-любому в виде библиотеки будет. Но не скоро.
                                        0
                                        вы еще АТМ и Frame Relay вспомните? том тоже много чего интересного
                                        • НЛО прилетело и опубликовало эту надпись здесь
                                            0
                                            Велосепидисты-извпащенцы detected

                                            ;)
                                              0
                                              ftn — оффлайн протокол, не требующий поддержки коннекта 24/7.
                                              А у вас?
                                                0
                                                Аналогично.
                                                0
                                                Я в танке, для решения каких проблем нужна разработка этого протокола?
                                                    0
                                                    Все что нужно для решения ваших задач есть, но мешала сложность настройки.
                                                    То есть реально, новый протокол нужен только для того чтоб упростить использование старых?
                                                      0
                                                      Да.
                                                      Но упрощение не только на пользовательском (в плане настроек), но и на техническом уровне — единый простой и удобный формат сетевого сообщения. В частности — легко разбираемая секция параметров, позволяющая испорльзовать базовый формат пакета для многих приложений без необходимости инкапсуляции пакетов одного формата в другой.

                                                      Например, почта. Современный email — это текстовый файл, состоящий их кучи строк заголовков и вложений в виде блоков текста, в котором закодированы в BASE64 бинарные данные. Все это приходится парсить целиком, а бинарные данные раскодировать из BASE64. Жопа еще та, просто за большое время использования хорошо отлаженная.

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

                                                  0

                                                  Чем все закончилось?
                                                  Мне реально интересен ваш опыт и результат.
                                                  Создан новый протокол, настроили старые компоненты или просто задача отпала?

                                                    +1
                                                    Проект заглох за ненадобностью, но отдельные части кода, идеи и наработки применяются в системе приема извещений от охранных и пожарных приборов на пультах центрального наблюдения МЧС и МВД Республики Беларусь. Будет спрос — реанимирую проект на новом уровне качества и защиты.
                                                      0

                                                      Можете рассказать про децентрализованную часть?

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

                                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                  Самое читаемое