MQTT знает, подписан ли клиент

Вопрос уже опубликован, Mqtt Как клиент может узнать, подключен ли другой клиент или нет и Как найти сведения о подключенном MQTT-клиенте

В моем случае, если клиент X уже подписан на канал A, клиент Y не может подписаться на канал A, пока X не отпишется. У меня может быть только один клиент, подписанный на канал

Могу ли я также использовать идею сохраненных сообщений и LWT?

Если да, то я точно не знаю, с чего мне начать. Было бы хорошо начать с простого примера, чтобы увидеть, как работают сохраненные сообщения и LWT. Пока что у меня есть только опыт публикации и подписки, но не более того.

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


java mqtt paho
person marhg    schedule 12.08.2016    source источник
comment
Почему тебе нужен только один подписчик?   -  person hardillb    schedule 12.08.2016
comment
потому что клиент этого хочет. Идея состоит в том, чтобы иметь разные типы связи: один издатель/один клиент, много издателей/много клиентов. Поэтому есть каналы, которые могут иметь только одного подписчика, но также я могу публиковать те же данные, но в другом канале, который допускает большее количество подписчиков. Например, температура канала принимает только одного подписчика, а температура2 — много.   -  person marhg    schedule 12.08.2016

Ответы (1)


arrow_upward
3
arrow_downward

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

Возможно, вы сможете реализовать что-то вроде следующего:

Если у вас есть тема, скажем foo/bar, и вам нужен только один подписчик, вы можете опубликовать сохраненное сообщение с полезной нагрузкой идентификатора клиента подписчика для lock/foo/bar. Затем вы можете опубликовать «бесплатно» в этой теме блокировки, когда вы отключитесь, и настроить LWT, чтобы сделать то же самое в случае смерти клиента.

Проблема в том, что все асинхронно, поэтому открывается много временных окон для условий гонки. например скажем, client-1 и client-2 оба хотят подписаться на foo/bar, им обоим нужно сначала подписаться на lock/foo/bar, чтобы проверить его состояние. Они оба делают это почти одновременно, затем им приходится некоторое время ждать, чтобы увидеть, какое сообщение они вернут («бесплатно» или идентификатор клиента). Они оба получат «бесплатно», поэтому оба предполагают, что могут публиковать свои идентификаторы клиентов. Сначала публикуется client-1, затем client-2, а затем они оба подписываются на foo/bar.

person hardillb    schedule 12.08.2016
comment
Привет hardillb, да, вы правы с проблемой. Но тогда что может быть хорошей альтернативой? в другом посте я читал об отправке событий подписки на канал. тогда я думаю, что если кто-то хочет подписаться, ему нужно знать, есть ли уже событие подписки - person marhg; 12.08.2016
comment
По сути, я пытаюсь сказать, что с MQTT это невозможно. - person hardillb; 12.08.2016
comment
о нет! ... ну, я думаю, мой единственный вариант - это сохраненное сообщение и lwt, но я не знаю, как я решу проблему, по крайней мере, избегаю подписки одновременно :/. Знаете ли вы, где я могу найти небольшую реализацию с использованием сохраненного сообщения, я читал на hivemq.com, но не смог найти - person marhg; 12.08.2016
comment
сохраненное сообщение определено в setWill options.setWill(client.getTopic(home/LWT), я ушел :(.getBytes(), 0, false); правильно? но вы упомянули, что можете опубликовать сохраненное сообщение с полезная нагрузка идентификатора клиента подписчика на lock/foo/bar, но что, если я не знаю, кто является клиентом?или что вы имели в виду? - person marhg; 12.08.2016
comment
Клиент всегда должен знать свой собственный client-id - person hardillb; 12.08.2016
comment
Спасибо hardillb, попробую сделать небольшой пример. Увидимся в следующем посте ;) - person marhg; 12.08.2016