Czy konieczne jest utworzenie liczby ax tematów MQTT dla x liczby urządzeń?

Obecnie w moim projekcie, w którym kontroler (klient) wysyła dane czujnika do serwera i otrzymuje informacje zwrotne od serwera z dodatkowymi danymi, do komunikacji używa protokołu MQTT. Ma 2 oddzielne tematy dla klienta i serwera.

Na przykład:

Temat 1 - Klient (SUBSKRYBUJE), Serwer ( OPUBLIKUJE )
Temat 2 - Klient (OPUBLIKUJE), Serwer (SUBSKRYBUJE)

Ale jeśli ten projekt jest przykładem zastosowania większej aplikacji, powiedzmy, że gdzieś trzeba zainstalować jakieś 5000 urządzeń.

Czy zatem konieczne będzie utworzenie 5000 różnych tematów dla klienta i serwera? Lub przy mniejszych tematach można to zrobić i jak?

mqtt

— ron123456
źródło

Jak myślisz, dlaczego problem ma wiele tematów?

— hardillb

Prawdopodobnie dlatego, że oprogramowanie musiałoby zarządzać nimi wszystkimi.

— Mawg mówi o przywróceniu Moniki

@hardillb To nie jest problem ... po prostu byłem ciekawy ... ale czy temat MQTT może mieć podtemat?

— ron123456

Jasne, tematy są hierarchiczne, więc można opracować dowolny schemat. Sparkplug s3.amazonaws.com/cirrus-link-com/... ma kilka wątków na węźle brzegowym i urządzenia za węzła brzegowego.

— Wsparcie Gambit

spójrz na to shiftr.io/shiftr-io/demo

— jsotola

Od klienta do serwera można spakować identyfikator klienta do ładunku, np. Jeśli jest to JSON, jeden z kluczy może mieć wartość identyfikatora klienta.

Odpowiedź od serwera do klienta powinna zawierać identyfikator klienta, aby pośrednik nie wysyłał wiadomości, ale wysyłał ją bezpośrednio do jednego podłączonego klienta.

W tym samym czasie możesz subskrybować swój serwer na coś w rodzaju: „request / +”, a każdy klient opublikuje na „request / {client-id-1}”, „request / {client-id-2}” i serwer otrzyma oba z tylko jedną subskrypcją.

— shal
źródło