Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 76
Почему у вас ни слова про OSPF, ни даже про занюханный RIP?
На данный момент предусмотрено автоматическое выстраивание сети в виде дерева, а там несколько проще с маршрутизацией. Просто таблица даунлинков, а все остальное идет на аплинк. Для сетей в сотню узлов вполне достаточно, IMHO.
Когда будет стабильно работать упрощенный вариант топологии, тогда можно будет экспериментировать с более сложной топологией и более хитрой авто-маршрутизацией, учитывающей проходимость в оба конца линка, множественные каналы, итд…
Когда будет стабильно работать упрощенный вариант топологии, тогда можно будет экспериментировать с более сложной топологией и более хитрой авто-маршрутизацией, учитывающей проходимость в оба конца линка, множественные каналы, итд…
Дерево? Я правильно понимаю, что для того, чтобы всё это поломать достаточно сломать корневой узел?
Линки сломанного узла подключатся к другому узлу. Смотрите схему.
Если «подключатся к другому узлу», то это уже не дерево, а граф. Для этого не нужно ничего рисовать, чистая математика.
Если не более одного аплинка, то по-любому дерево получается.
т.е. не существует узлов с двумя «аплинками»? и в худшем случае пакет в сети из n узлов проходит n-1 ребро?
масштабируемо однако.
масштабируемо однако.
Предусмотрена возможность настроить аплинков и роутинг на них вручную.
Если я начну сразу делать самонастраиваемый граф на 100500 узлов, то скорее всего, ничего хорошего не выйдет. Сколько человеко-часов (вернее, человеко-лет) ушло у DARPA и прочих разработчиков действующих сетей? Да и то, начинали с простых вещей — RIP и тому подобного.
Проблема масштабируемости пока не стоит. Я и десяток узлов пока толком протестировать не могу — глаза разбегаются, нужно инструменты создавать.
Если я начну сразу делать самонастраиваемый граф на 100500 узлов, то скорее всего, ничего хорошего не выйдет. Сколько человеко-часов (вернее, человеко-лет) ушло у DARPA и прочих разработчиков действующих сетей? Да и то, начинали с простых вещей — RIP и тому подобного.
Проблема масштабируемости пока не стоит. Я и десяток узлов пока толком протестировать не могу — глаза разбегаются, нужно инструменты создавать.
так они еще и железо паяли
+ для них не было никаких наработанных идей
+ у них и инструментов-то никаких не было
+ они творили что-то принципиально новое
а сейчас чего: открыл сокет и хреначь туда чего хочешь. а операционная система сама уже позаботится о транспорте. ну не она конечно, а OSI.
в любом случае проект классный, плюсик поставил.
+ для них не было никаких наработанных идей
+ у них и инструментов-то никаких не было
+ они творили что-то принципиально новое
а сейчас чего: открыл сокет и хреначь туда чего хочешь. а операционная система сама уже позаботится о транспорте. ну не она конечно, а OSI.
в любом случае проект классный, плюсик поставил.
Если аплинк один «в принципе», то когда он дохнет, вся ветка дерева дохнет.
Если есть резервные аплинки, то это уже не дерево, а граф, в котором есть активные и пассивные грани.
Поверьте мне, этот вопрос много и серьёзно прорабатывали до вас — потому я и написал «почему ни слова про ospf?»
Если есть резервные аплинки, то это уже не дерево, а граф, в котором есть активные и пассивные грани.
Поверьте мне, этот вопрос много и серьёзно прорабатывали до вас — потому я и написал «почему ни слова про ospf?»
Представьте, что Талария это ad-hoc IP сеть, в которой только UDP-пакеты с подтверждением о доставке (без сеансового уровня). Ничего там не сдохнет, просто маршруты по умолчанию перестроятся и пакеты побегут по новому маршруту. На уровне приложений вообще ничего не произойдет.
Когда вы говорите «пакеты побегут», у меня возникает ощущение, что вы говорите не об ИП-сетях. Напоминаю, что в IP-сетях используется однохоповая маршрутизация (маршрутизатор ничего не знает о полном маршруте, и только перекладывает пакеты слева на право согласно своим табличкам).
И каким же образом вы собираетесь исключать циклы? Узел А отдаёт пакет узлу Б, узел Б узлу С, узел С узлу Д, а тот отдаёт его обратно А.
И каким же образом вы собираетесь исключать циклы? Узел А отдаёт пакет узлу Б, узел Б узлу С, узел С узлу Д, а тот отдаёт его обратно А.
Сообщения содержат список узлов, через которые они прошли.
Ага, то есть мы отказываемся от stateless маршрутизации и начинаем себя искать в пути. В этом случае аналогии с IP крайне ошибочны, правильнее говорить «подобные электронной почте».
В этом случае возникает другой вопрос: а почему обязательно использовать единственный маршрут? Что мешает отправлять сообщения разными путями, балансируя нагрузку?
В этом случае возникает другой вопрос: а почему обязательно использовать единственный маршрут? Что мешает отправлять сообщения разными путями, балансируя нагрузку?
Совершенно верно, это скорее почтовая сеть. Со всеми плюсами и минусами.
Единственный маршрут прост в реализации. В дальнейшем попробую реализовать Дейкстру с учетом цены пути. Главное, чтобы он был достаточно простым в реализации и не требовал много ресурсов.
Вопрос в том, как скоро это понадобится. Талария использует двухуровнувую маршрутизацию, поэтому огромное число абонентов можно держать в сети из всего лишь десятка узлов. Думаю, между десятком узлов с маршрутизацией особых проблем не будет.
Единственный маршрут прост в реализации. В дальнейшем попробую реализовать Дейкстру с учетом цены пути. Главное, чтобы он был достаточно простым в реализации и не требовал много ресурсов.
Вопрос в том, как скоро это понадобится. Талария использует двухуровнувую маршрутизацию, поэтому огромное число абонентов можно держать в сети из всего лишь десятка узлов. Думаю, между десятком узлов с маршрутизацией особых проблем не будет.
Никогда не рассчитывайте, что 4 миллиардов адресов хватит надолго (С) ipv4.
Если по сути — зачем изобретать сохранение пути, если можно использовать stateless маршрутизацию и отдельный протокол, собственно, маршрутизации?
Обратите внимание, что сам протокол (тот же OSPF) позволяет автоматически прокладывать путь, даже если произошёл сложный обрыв.
Представьте себе такую схему:
Вам нужно передать сообщение от A к J. Ближайший маршрут — через B-E-F или через B-D-F
Сообщение дошло до B, в этот момент F упал. Сообщение идёт до E, оттуда до D, возвращается к B, обнаружен цикл, сообщение не доставлено. Хотя можно было бы это пустить через C и далее.
Таких циклов можно много наворотить. Как решать будете?
Если по сути — зачем изобретать сохранение пути, если можно использовать 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 и далее.
Таких циклов можно много наворотить. Как решать будете?
IPv4 еще дышит (и будет еще дышать) благодаря NAT. Без него адреса уже давно бы кончились. А если сделать аналог NAT в Таларии, то трудно представить, сколько абонентов сможет обслужить такая сеть.
Вы нарисовали граф, а я ориентировался на дерево. Впрочем, вполне возможно, что описанная ситуация случится и в дереве. Если сообщение зашло в тупик, то придется анализировать пройденный путь и выбирать другой маршрут. Или тупо убить сообщение, как это делается в IP при истекании TTL.
Вы нарисовали граф, а я ориентировался на дерево. Впрочем, вполне возможно, что описанная ситуация случится и в дереве. Если сообщение зашло в тупик, то придется анализировать пройденный путь и выбирать другой маршрут. Или тупо убить сообщение, как это делается в IP при истекании TTL.
… И опять же, это не дерево, а построение пути в графе с использованием стека.
Не похоже это на дерево, циклы-то должны иметься, хотя бы для резервирования.
Что-то мне подсказывает, что в ближайшее время появятся несколько хороших, но несовместимых IM-протоколов.
Delphi… *поблевал*
FTN, конечно, была интересной сетью…
Если уж делать такой проект, то кроссплатформенным. Одни из самых востребованных клиентов — для смартфонов, как с этим у дельфи? Идея интересная, наличие документации и реализации, это огромный плюс. «Коммерческая версия протокола» — удивляет. Как протокол может быть коммерческим?
Если уж делать такой проект, то кроссплатформенным. Одни из самых востребованных клиентов — для смартфонов, как с этим у дельфи? Идея интересная, наличие документации и реализации, это огромный плюс. «Коммерческая версия протокола» — удивляет. Как протокол может быть коммерческим?
Чтобы придумать и испытать новый протокол, нужен максимально удобный инструмент. Дельфи (а точнее, ее IDE, библиотеки классов и компонентов) лучше всего подходит для работы над сложными вещами в одиночку, экономит кучу времени. Результатом работы будет общедоступное описание протокола, который можно реализовать на чем угодно и кем угодно.
Коммерческая версия — использующая сторонние патентованные технологии, и ориентированная на бизнес-приложения. В ней будет упор на безопасность и контроль. Позиционируется для систем, работающих с платежами, персональными данными и прочими секретами.
Коммерческая версия — использующая сторонние патентованные технологии, и ориентированная на бизнес-приложения. В ней будет упор на безопасность и контроль. Позиционируется для систем, работающих с платежами, персональными данными и прочими секретами.
уж C# хотя бы или java.
Но никак не труп, как бы печально это не было.
Но никак не труп, как бы печально это не было.
Ой, Тотал Коммандер написан на Дельфи…
Да и вы таки не поверите, сколько ещё всего вокруг вас ;)
Да и вы таки не поверите, сколько ещё всего вокруг вас ;)
Тотал Коммандер был начат на Дельфи, когда Дельфи еще в соку было. не переписывать же им его. поэтому TC совершенно не показатель. вы лучше приведите примеры новых программ, написаных на Дельфи.
(Сам в свое время перешел на .net с Дельфи, потому что от Дельфи начало попахивать мертвечинкой)
(Сам в свое время перешел на .net с Дельфи, потому что от Дельфи начало попахивать мертвечинкой)
qip на делфи. и до того как его купили был очень даже стабилен и шустр, сейчас согласен он медленно катится к состоянию клиента аси.
Список программ можете посмотреть здесь
ru.wikipedia.org/wiki/Delphi_(язык_программирования)
Заодно и узнаете, что среда может генерировать и .NET код.
ru.wikipedia.org/wiki/Delphi_(язык_программирования)
Заодно и узнаете, что среда может генерировать и .NET код.
Примерно нуль, т. к. дельфи windows only, на lazareus пожалуй знаю только PeaZip, а на Kylix только TuxCmd.
Если не ошибаюсь, биндинги к lazareus'овским библиотекам не слишком тривиальны и могут требовать специфичные runtime компоненты, соответственно можно забыть о включение в purple/telepathy.
Если не ошибаюсь, биндинги к lazareus'овским библиотекам не слишком тривиальны и могут требовать специфичные runtime компоненты, соответственно можно забыть о включение в purple/telepathy.
спросите у Skype
Где векторы? Где гипертекст, я вас спрашиваю?
статья интересная, и картинки такие красивые. но хочется задать стандартный вопрос:
какие актуальные задачи решает данный протокол?
я пока не понял.
какие актуальные задачи решает данный протокол?
я пока не понял.
обучение и развитие еще одного хорошего отечественного разработчика =)
это видимо как у веб-программистов: пока свою цмс не напишут — не успокоятся и не начнут заниматься чем-то серьезным.
это видимо как у веб-программистов: пока свою цмс не напишут — не успокоятся и не начнут заниматься чем-то серьезным.
вот и мне так кажется. статья интересная, но хочется, чтобы разработчик правильно позиционировал свою разработку.
а вот по-моему в подчеркнутом вами случае велосипедостроение очень очень много пользы приносит — например неплохое владение языком и технологиями + понятие устройства CMS, так что с реальными потом легче становится работать. Хотя ничего не могу утверждать, ибо веб-разработка не есть суть моих занятий, так сталкивался иногда по воле судьбы(а точнее острой нехватки денег), хотя до сих пор теплится надежда, что время найдется и я снова этим займусь. ой, господи, понесло меня что-то после пива) вобщем ИМХО)
По идее точно так же можно набираться опыта, изучая сторонние CMS.
Просто больная тема для меня. Видел уже несколько сапописных финансовых систем, которые были написаны с нуля «по приколу». Все бы хорошо, но вот только они не удовлетворяют почти никаким требованиям финансовых систем (почти никогда не контролируется целостность и полнота данных, или это реализуется абсолютно не на том уровне на котором следовало бы (например на уровне приложения)).
И это еще не плохо, но иногда случается так что эти самобытные системы начинают покупаться и внедряться. И вот тут уже совсем хана
Просто больная тема для меня. Видел уже несколько сапописных финансовых систем, которые были написаны с нуля «по приколу». Все бы хорошо, но вот только они не удовлетворяют почти никаким требованиям финансовых систем (почти никогда не контролируется целостность и полнота данных, или это реализуется абсолютно не на том уровне на котором следовало бы (например на уровне приложения)).
И это еще не плохо, но иногда случается так что эти самобытные системы начинают покупаться и внедряться. И вот тут уже совсем хана
Идея этого протокола возникла после двухчасового гимора с линкованием двух IRC серверов. Там реально ничего сложного, но в первый раз пришлось прочитать кучу документации, изучить от корки до корки конфиг…
Еще мне по работе нужна была сеть обмена данными с филиалами. Тогда (года 3 назад) с интернетами был напряг, и единственным надежным способом передачи данных в автономном режиме был фидошный софт. Но его настраивать — тоже дело весьма непростое. Удаленно настроить (общаясь по телефону с женщиной-оператором ПЭВМ) было практически нереально.
Сейчас же можно использовать Таларию как основу сети мобильных устройств ограниченного радиуса действия. Или как подпольную неконтролируемую сеть, способную работать в условиях постоянных обрывов связи и изменения состава участников. Или просто для чата в городской локалке.
Еще мне по работе нужна была сеть обмена данными с филиалами. Тогда (года 3 назад) с интернетами был напряг, и единственным надежным способом передачи данных в автономном режиме был фидошный софт. Но его настраивать — тоже дело весьма непростое. Удаленно настроить (общаясь по телефону с женщиной-оператором ПЭВМ) было практически нереально.
Сейчас же можно использовать Таларию как основу сети мобильных устройств ограниченного радиуса действия. Или как подпольную неконтролируемую сеть, способную работать в условиях постоянных обрывов связи и изменения состава участников. Или просто для чата в городской локалке.
IRC тоже не самое свежее что есть в мире.
По поводу мобильных устройств есть Zigbee, который все это уже умеет. По поводу подпольного интернета, то он тоже уже есть! называется I2P.
Да и кстати на каком уровне сетевого стека должна жить Талария? Она поверх TCP/IP или ниже?
По поводу мобильных устройств есть Zigbee, который все это уже умеет. По поводу подпольного интернета, то он тоже уже есть! называется I2P.
Да и кстати на каком уровне сетевого стека должна жить Талария? Она поверх TCP/IP или ниже?
Да и кстати на каком уровне сетевого стека должна жить Талария? Она поверх TCP/IP или ниже?
Она вообще отдельно, ей не нужен носитель. Хоть поверх голубиной почты. =)
Она вообще отдельно, ей не нужен носитель. Хоть поверх голубиной почты. =)
А в прототипе что используется? UDP?
ТСР для имитации линков и DDE для мониторинга.
DDE? ну вот этого не надо, пожалуйста.
Предложите что-то лучше для мониторинга десятков запущенных локально копий приложения. Сейчас это сделано буквально тремя строками кода, и работает именно так, как надо.
сокет/пайп?
Сокеты сложны и капризны, даже UDP сокет сложнее, чем DDE. Пайпы не разделяются копиями приложения, вторая копия уже не сможет работать с пайпом, который занят первой копией.
Неправда Ваша. Во-первых, сокеты просты как грабли, особенно UDP. Во-вторых, сокеты несомненно проще чем любой DDE, даже DDEML, не говоря уже о родном DDE API. В-третьих, в VCL/LCL, насколько я помню, есть очень замечательные обёртки, которые делают программирование сокетов просто сказкой (хотя, до, например, тиклевых и перловых обёрток им далеко).
Для сокетов нужно писать обработку ошибок, а для серверных еще и обработку и синхронизацию потоков — современные обертки (Indy, Synapse) принимают входящие пакеты в отдельных потоках, даже для UDP.
В DDE все гораздо проще. Есть текст (набор строк), который расшарен между приложениями. Если кто-то его меняет, то у других срабатывает Event, что текст изменился. Все!
Или можно тупо отправить клиентом на сервер текстовое сообщение dde.PokeData('Bla-bla-bla') — никаких коннектов, хостов, таймаутов, и прочей херни. Сервер тоже может сделать то же самое, тогда сообщение получат разом все клиенты.
То, что DDE очень старая технология (еще со времен Windows 2.0) — не значит, что она плохая.
В DDE все гораздо проще. Есть текст (набор строк), который расшарен между приложениями. Если кто-то его меняет, то у других срабатывает Event, что текст изменился. Все!
Или можно тупо отправить клиентом на сервер текстовое сообщение dde.PokeData('Bla-bla-bla') — никаких коннектов, хостов, таймаутов, и прочей херни. Сервер тоже может сделать то же самое, тогда сообщение получат разом все клиенты.
То, что DDE очень старая технология (еще со времен Windows 2.0) — не значит, что она плохая.
Так, смотрим в man send (2):
Казалось бы, что проще? Никаких коннектов, таймаутов и так далее.
И я не вижу, где в DDE хоть что-либо проще. DDE — типичный пример over-engineered technology. И таки да, DDE — ужасная технология. Как, впрочем и OLE/COM.
P.S. Да, я понимаю, что с точки зрения TDDEClient.Create эта технология кажется действительно очень простой, но, поверьте, зная, что у неё в потрохах (да, я видел DDEML и то, что было до него), сказать, что DDE прост, язык не поворачивается.
P.P.S. А вообще, завязываться на архаичную непортируемую технологию крайне неразумно.
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. А вообще, завязываться на архаичную непортируемую технологию крайне неразумно.
> Можно и на C/C++ переписать, но я буду очень скучать без VCL.
Я так понимаю, на безиксовой машинке клиент не запустишь. Рекомендую хотя бы функциональность как-нибудь отделить от гуя и переписать на С.
Я так понимаю, на безиксовой машинке клиент не запустишь. Рекомендую хотя бы функциональность как-нибудь отделить от гуя и переписать на С.
вы еще АТМ и Frame Relay вспомните? том тоже много чего интересного
Велосепидисты-извпащенцы detected
;)
;)
ftn — оффлайн протокол, не требующий поддержки коннекта 24/7.
А у вас?
А у вас?
Я в танке, для решения каких проблем нужна разработка этого протокола?
Все что нужно для решения ваших задач есть, но мешала сложность настройки.
То есть реально, новый протокол нужен только для того чтоб упростить использование старых?
То есть реально, новый протокол нужен только для того чтоб упростить использование старых?
Да.
Но упрощение не только на пользовательском (в плане настроек), но и на техническом уровне — единый простой и удобный формат сетевого сообщения. В частности — легко разбираемая секция параметров, позволяющая испорльзовать базовый формат пакета для многих приложений без необходимости инкапсуляции пакетов одного формата в другой.
Например, почта. Современный email — это текстовый файл, состоящий их кучи строк заголовков и вложений в виде блоков текста, в котором закодированы в BASE64 бинарные данные. Все это приходится парсить целиком, а бинарные данные раскодировать из BASE64. Жопа еще та, просто за большое время использования хорошо отлаженная.
В моем случае, есть секция параметров, где описаны заголовки и вложения. И отдельная секция данных, где лежат вложения. При маршрутизации письма, секция данных не затрагивается, а секция параметров легко разбирается и дополняется. Вложения тоже лкгко считываются, если в параметрах указаны размеры вложений и их смещения от начала. Или в секции данных может находиться обычный zip-архив с вложениями.
Но упрощение не только на пользовательском (в плане настроек), но и на техническом уровне — единый простой и удобный формат сетевого сообщения. В частности — легко разбираемая секция параметров, позволяющая испорльзовать базовый формат пакета для многих приложений без необходимости инкапсуляции пакетов одного формата в другой.
Например, почта. Современный email — это текстовый файл, состоящий их кучи строк заголовков и вложений в виде блоков текста, в котором закодированы в BASE64 бинарные данные. Все это приходится парсить целиком, а бинарные данные раскодировать из BASE64. Жопа еще та, просто за большое время использования хорошо отлаженная.
В моем случае, есть секция параметров, где описаны заголовки и вложения. И отдельная секция данных, где лежат вложения. При маршрутизации письма, секция данных не затрагивается, а секция параметров легко разбирается и дополняется. Вложения тоже лкгко считываются, если в параметрах указаны размеры вложений и их смещения от начала. Или в секции данных может находиться обычный zip-архив с вложениями.
Чем все закончилось?
Мне реально интересен ваш опыт и результат.
Создан новый протокол, настроили старые компоненты или просто задача отпала?
Проект заглох за ненадобностью, но отдельные части кода, идеи и наработки применяются в системе приема извещений от охранных и пожарных приборов на пультах центрального наблюдения МЧС и МВД Республики Беларусь. Будет спрос — реанимирую проект на новом уровне качества и защиты.
Можете рассказать про децентрализованную часть?
Да, там все просто. Каждый отдел в каждом городе использует автономный узел, не имеющий связи с внешним миром, только с приборами в изолированых сетях, и не напрямую, а через специальные модули связи. Но есть возможность слать все новые данные на другой узел — это может быть как резервный сервер для горячей замены, так и «вышестоящий», региональный узел. Каждый элемент данных имеет глобально-уникальный идентификатор, поэтому возможен обмен между любыми узлами без конфликтов, при этом видно, где созданы данные и где они побывали.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Distributed Network Messaging Protocol — хорошо забытый FTN