Нужно ли создавать топор по темам MQTT для x количества устройств?

В настоящее время в моем проекте, в котором контроллер (клиент) отправляет данные датчика на сервер и получает обратную связь от сервера с некоторыми дополнительными данными, использует протокол MQTT для связи. Он имеет 2 отдельные темы для клиента и сервера.

Например:

Topic1 - Клиент (ПОДПИСЫВАЕТСЯ), Сервер ( ИЗДЫВАЕТ )
Topic2 - Клиент (ИЗДАЕТСЯ), Сервер (ПОДПИСЫВАЕТСЯ)

Но если этот проект является вариантом использования более крупного приложения, скажем, где-то нужно установить около 5000 устройств.

Итак, нужно ли будет создать 5000 различных тем для клиента и сервера? Или с меньшими темами это можно сделать и как?

mqtt

— ron123456
источник

Почему, по-вашему, проблематично иметь много тем?

— Hardillb

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

— Mawg говорит восстановить Монику

@hardillb Это не проблема ... просто было любопытно ... но может ли тема MQTT иметь подтему?

— ron123456

Конечно, темы являются иерархическими, поэтому можно разработать любую схему. Sparkplug s3.amazonaws.com/cirrus-link-com/… имеет несколько тем для каждого краевого узла и устройства за краевым узлом.

— Поддержка Gambit

взгляните на этот shiftr.io/shiftr-io/demo

— jsotola

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

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

В то же время вы можете подписать свой сервер на что-то вроде: «запросы / +», и каждый клиент будет публиковать в «запрос / {client-id-1}», «запрос / {client-id-2}» и сервер получит оба с одной подпиской.

— ШЭЛ
источник