Pull to refresh

Comments 5

Звезда — на сегодняшний день самая распространенная топология компьютерных сетей.

Зависит, конечно, от определений, но вообще нет. Если считать интернет самой большой и объемной компьютерной сетью, то в основе такой сети исторически дерево, дополненное до многоуровневого графа. Если считать топологией не только железки, но и гиперпространство поверх них, то всякие умные люди, пишущие статьи, придумали для этого термины Jellyfish (медуза), либо Bow Tie (галстук-бабочка).
Такая структура обладает рядом преимуществ: [...] надежностью

Я вас умоляю. По-моему, это в книжках только при сравнении с токенрингом или firewire пишут. Коммутатор — single point of failure, куда ж ненадежнее.
А если по существу — то вы написали n+1-ую messaging bus. Поясните, что ли, чем она лучше всех существующих и стандартизированных решений (всех MQ, ESB / JMS, ORB, MQTT, да хоть того же dbus — в общем, в википедии есть не такой маленький список)? Насколько я понимаю, не то, что нет гарантированной доставки, а нет даже концепции очереди и какого-то ее хранения? Сообщения, судя по коду, пакуются в JSON — не кажется ли, что это как-то, несколько неоптимально для внутрипрограммной шины?
Ну застрял человек немного в прошлом, ну бывает :) Сам хотел написать про звезду и надежность.
Зависит, конечно, от определений, но вообще нет. Если считать интернет самой большой и объемной компьютерной сетью, то в основе такой сети исторически дерево, дополненное до многоуровневого графа. Если считать топологией не только железки, но и гиперпространство поверх них, то всякие умные люди, пишущие статьи, придумали для этого термины Jellyfish (медуза), либо Bow Tie (галстук-бабочка).

У дерева a priori есть корень. Где же корень интернет?)
Я уверен, что у большинства читателей как минимум дома стоит роутер, к которому цепляются остальные железки, а это и есть звезда.
Вообще-то в тексте сразу поясняется, о какой надежности речь: «(выход из строя одной машины не сказывается на других)». Конечно, выход из строя концентратора приведет к выходу из строя всей сети. Именно поэтому программная реализация ядра должна быть предельно проста и надежна.
А если по существу — то вы написали n+1-ую messaging bus
– абсолютно верно.
Поясните, что ли, чем она лучше всех существующих и стандартизированных решений
– наверно минимализмом. Ну в самом деле, посмотрите в исходники существующих решений
Насколько я понимаю, не то, что нет гарантированной доставки, а нет даже концепции очереди и какого-то ее хранения?
– Если нужно, добавить очередь в methanum, не так-то и сложно.
Сообщения, судя по коду, пакуются в JSON — не кажется ли, что это как-то, несколько неоптимально для внутрипрограммной шины?
— Сами события сериализуются в бинарный формат, при этом по умолчанию они могут содержать словарь примитивов (int, double, bool…). Т.к. первоначально система создавалась для сбора и обработки данных с промышленных контроллеров, где примитивов было вполне достаточно. Если нужно передавать пользовательскую структуру, можно добавить ее в качестве известного типа, например «[KnownType(typeof(List))]». Или можно запаковать объект ну скажем в строку, в данном случае в JSON. И кстати нигде и речи не идет, что данное решение исключительно внутрипрограммное.

Данная статья задумывалась, чтобы поделиться опытом, как сделать программную реализацию звезды своими руками, без каких либо зависимостей и сторонних проектов. Проект methanum абсолютно не претендует на звание нового и уникального инструмента. Однако, в некоторых случаях может быть очень полезен, его можно быстро заточить под свои нужды.
Сравнения с MQTT, WAMP или ZeroMQ не хватает. Добавьте, если есть возможность.
Sign up to leave a comment.