идем на уровень ниже... то, что паблишер начинает с "/lorem", означает, что сабскрайберу надо об этом знать, иначе не подписаться

Ох, ну это-то да. Но можно сделать какой-то системный топик, допустим "/sys/topics", и через него получать список топиков, на которые в последствии подписываться

но это должен уметь делать брокер

в общем, я понял, что брокер - это помойка, которая умеет хорошо сортитовать мусор и отдавать записавшимся

но это должен уметь делать брокер

Брокер же вообще ничего не должен уметь, кроме как роутить пакеты. Остальное — уровень приложения.

в общем, я понял, что брокер - это помойка, которая умеет хорошо сортитовать мусор и отдавать записавшимся

Ну ещё аутентифицирует и сортирует пакеты по QoS.

кстати про QoS

если я правильно понял, то уровень QoS определяет посылатель, так?

для данных, разумеется

Ага, для каждого сообщения.

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

или я туплю?

+ retain

Оно идёт с заданным QoS до брокера и отправитель про него забывает. Потом брокер смотрит всех подписчиков на данный момент, и отсылает им пакет, либо прося прислать подтверждение (QoS=1), либо делая хендшейк (QoS=2).

похоже, что ключевое - "всех подписчиков на данный момент"

+ retain

Окей, retained message запоминается брокером вместе с его QoS, и потом отдаётся всем вновь подписавшимся, а уровень QoS становится глобальным для этого топика.

Скорее, не глобальным, а стандартным.

ок. а когда забывает?

только если попросят?

Retained messages should be kept over restarts of the server. A server may delete a retained message if it receives a message with a zero-length payload and the Retain flag set on the same topic.

Retained messages should be kept over restarts of the server. A server may delete a retained message if it receives a message with a zero-length payload and the Retain flag set on the same topic.

Ну то есть, да, или пока брокер не перезапустят, или пока ты не отправишь пустое retained message.

замечательная метода завалить сервер надолго ненужными данными

замечательная метода завалить сервер надолго ненужными данными

Учитывая лимит в одно такое сообщение на топик — то норм.

Вообще, я чёта никогда не задумывался что это очень удобно.

ну да, подписался - и сразу же получил последние данные, без ожидания новых

Учитывая лимит в одно такое сообщение на топик — то норм.

убедил, не сильно страшно, только жаль нет на них таймаута, чтобы подчищать за навсегда исчезнувшими клиентами

убедил, не сильно страшно, только жаль нет на них таймаута, чтобы подчищать за навсегда исчезнувшими клиентами

Если у тебя есть какой-то контроллирующий элемент — то можно написать эту логику самому, отлавливая LWT и дисконнекты.

Если у тебя есть какой-то контроллирующий элемент — то можно написать эту логику самому, отлавливая LWT и дисконнекты.

ах да, дисконнекты... я так понимаю, нет стандартной возможности узнать, присоединен ли источник моих подписок или нет?

Отловить дисконнект - да, нельзя, особенность концепции протокола. Только если это нормальное (запланированное) отключение, можно отправлять LWT.

В иных случаях - только heartbeat на своей логике.

пинг-понг?

В иных случаях - только heartbeat на своей логике.

пичалька

пинг-понг?

это означает логику вне протокола

угу, смотрю одна и та же проблема у всех протоколов ))

друган 15 лет решал это гавно в штатах

у OPC UA нет этой болезни, но там протокол и псложнее и понавороченнее

Отловить дисконнект - да, нельзя, особенность концепции протокола. Только если это нормальное (запланированное) отключение, можно отправлять LWT.

Хотя, стоп.

Опять грёбанное критическое мышление.

Отлавливать нормальный дисконнект можно на брокере.

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

под нормальным дисконнектом подразумевается - "bye" !?

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

тоже можно, по tcp timeout-у

под нормальным дисконнектом подразумевается - "bye" !?

да, DISCONNECT message

скользкая дорожка, имхо ))

просто мне иногда жизненно важно знать, это (новых) данных нет или связи нет

Отлавливать нормальный дисконнект можно на брокере.

означает, кстати, что нужен нестандартный брокер

в нормальном протоколе, буе выполняется как: - Разрыв связи, как понял, прием... - Разрыв связи, вас понял, прием... - дисконнект... Но где гарантия, что разрыв связи не произойдет где-то между? И что самое стремное, следующий на очереди, может уйти по таймауту, потому что брокер еще ждет ответа от первого.

означает, кстати, что нужен нестандартный брокер

В mosquitto есть расширяемый функционал, но не уверен что настолько расширяемый. Точно знаю что он позволяет дописывать свои плагины авторизации. А так, я писал свой брокер, как раз чтобы мониторить сеть на уровне протокола. В Node.js, например, это было очень просто с модулем Mosca.

означает, кстати, что нужен нестандартный брокер

?

Именно так все и делают, и стандарта нет ?

?

и началось... ?

В mosquitto есть расширяемый функционал, но не уверен что настолько расширяемый. Точно знаю что он позволяет дописывать свои плагины авторизации. А так, я писал свой брокер, как раз чтобы мониторить сеть на уровне протокола. В Node.js, например, это было очень просто с модулем Mosca.

я этого боялся... потому что стандартизация брокера означает, что данные можно послать "куда угодно", хоть через цепочку cloud-брокеров на другой конец мира, а так - теряется все преимущество стандарта

я этого боялся... потому что стандартизация брокера означает, что данные можно послать "куда угодно", хоть через цепочку cloud-брокеров на другой конец мира, а так - теряется все преимущество стандарта

Да, потому что большинство брокеров абсолютно неинтегрируемые.

это жестоко и отбивает охоту ? ведь кто есть брокер? кабель между двумя сетевушками...

просто мне иногда жизненно важно знать, это (новых) данных нет или связи нет

это невозможно, максимум что можно - таймаут на приход данных

или же "гарантированная доставка сообщения что источник закончил работу"

но например, если источник навечно отпилили от интернета

но например, если источник навечно отпилили от интернета

именно

я тут ща принимаю участие в качестве научного руководителя по диплому на эту тематику :)

распределенные mq без брокеров.

В нормальных условиях, источнику, которого отпиливают от интернета, сообщают, что он будет отпилен от интернета, чтобы он сообщил другим, и попрощался ?

нормальных да. а в ненормальных сначала отгнивает свитч

а потом выключают питание потому что сдох аккум упса, а дизель не завелся)

распределенные mq без брокеров.

Распределённые Message Queues?

Вкурсе, вкурсе ))

да

Чёта жёстко звучит.

это моя бредовая идея, которую я навязал практикантке в качестве диплома :)

ERROR: S client not available

приблизительная идея: в каждом процессе системы своя нода-брокер

она же сервер, она же клиент

Чёта жёстко звучит.

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

впилить протоколы консенсуса и продумать как реализовать гарантии доставки

и все это поверх коненчо же ADSL, wifi 3g и прочего плохо работоспособного интернета :)

Я бы еще назначал бродкастеров в сети, для оповещения о глобальных изменениях

и чтобы работало на mediatek linkit :)

да, можно протоколом консенсуса выбирать лидеров типа

которые будут вещать всем остальным

и нужно еще чо-то вроде spanning tree

вауваувау :)

строить таблицы маршрутизации поверх нестабильных и дублирующихся связей между нодами.

Не ожидал таки, что здесь способны обсуждать подобное :)

Алексу - успехов! ?

Не ожидал таки, что здесь способны обсуждать подобное :)

она анархическая, но все же электроника :)

короче, я думаю, тут одного консенсуса, транспортного слоя и написания пояснительной записки к диплому хватит чтобы все сошли с ума :)

?

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

в нее плагинами - парсеры-сериализаторы протоколов

протоколы асинхронные - пока stomp, потом вот можно mqtt впилить или чо нить такое

в нее плагинами - парсеры-сериализаторы протоколов

не ограничивайся компами!

и некий алгоритм, который поверх вот этого строит собственно сначала маршрутизацию

потом консенсусы и репликацию сообщений

в общем, боль :)

Не получится - просто вверх

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

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

дубликаты не надо ликвидировать

это невозможно без глобальных транзакций

тут либо планы репликации пересекаются с нижним - канальным, либо нижний - канальный, зависит от репликации и отношений

не, у меня ща в прототипе почти не пересекается

верхний уровень использует нижний.

в качестве среды передачи сообщений.