2016-08-12 5 views
0

Die Frage abonniert ist bereits gebucht, Mqtt How a client can get to know that another client is connected or not und How to Find Connected MQTT Client DetailsMQTT wissen, ob ein Kunde

In meinem Fall, wenn die Client-X bereits in einem Kanal A abonniert ist, Client Y an den Kanal A nicht Feed abonieren kann, bis X sich abmeldet. Ich kann nur einen Kunden im Kanal

haben Kann ich auch die Idee der beibehaltenen Nachrichten und LWT verwenden?

Wenn ja, weiß ich nicht genau woher soll ich anfangen. Es wäre gut, mit einem einfachen Beispiel zu beginnen, um zu sehen, wie die gespeicherten Nachrichten und LWT funktionieren. Bisher habe ich nur Erfahrung im Publizieren und Abonnieren, aber nicht mehr.

Könnten Sie bitte, sagen Sie mir, dass einige Ratschläge einige Links oder Beispiele oder nützliche Informationen sind, so kann ich einen Ausgangspunkt haben.

Ich programmiere in Java mit Paho.

Vielen Dank im Voraus!

+0

Warum möchten Sie nur einen Teilnehmer? – hardillb

+0

weil der Kunde das will. Die Idee ist, verschiedene Kommunikationsarten zu haben: ein Verlag/ein Kunde, viele Verleger/viele Kunden. Daher gibt es Kanäle, die nur einen Teilnehmer haben können, aber auch, ich kann die gleichen Daten veröffentlichen, aber in einem anderen Kanal, der mehr Abonnenten erlaubt.eg Kanaltemperatur akzeptiert nur einen Teilnehmer, während temperature2 viele – andreahg

Antwort

2

Bei MQTT geht es darum, dass mehrere Clients dieselben Themen abonnieren, es ist Teil des gesamten Pub/Sub-Musters und gibt Informationen frei. Es ist also nichts in das Protokoll eingebacken, das tun wird, was Sie wollen.

Unter Umständen können Sie so etwas wie das realisieren folgenden:

Wenn Sie ein Thema hat sagen foo/bar und Sie wollen nur einen Teilnehmer Sie eine Rückmeldung mit einer Nutzlast der Client-ID des Teilnehmers zu lock/foo/bar veröffentlichen könnten . Sie könnten dann ein "frei" für dieses Sperrthema veröffentlichen, wenn Sie die Verbindung getrennt und ein LWT eingerichtet haben, um dasselbe zu tun, falls der Client stirbt.

Das Problem dabei ist, dass alles asynchron ist, so dass es viele Zeitfenster für Rennbedingungen eröffnet. z.B. sagen client-1 und client-2 beide wollen foo/bar abonnieren, sie würden beide zuerst lock/foo/bar abonnieren müssen, um es zu prüfen, ist der Zustand. Beide tun dies fast zur gleichen Zeit, dann müssen sie einige Zeit warten, um zu sehen, welche Nachricht sie zurückbekommen ("frei" oder eine Client-ID). Sie würden beide "frei" bekommen und würden beide davon ausgehen, dass sie ihre Client-IDs veröffentlichen können. client-1 veröffentlicht zuerst kurz gefolgt von client-2 und dann beide abonnieren foo/bar.

+0

Hallo Hardillb, ja, du bist richtig mit das Problem. Aber was könnte eine gute Alternative sein? In einem anderen Beitrag habe ich gelesen, dass ich abonnierte Ereignisse an den Kanal sende. dann denke ich, dass, wenn jemand abonnieren möchte, er wissen muss, ob es bereits ein Abonnement-Ereignis gibt – andreahg

+0

Grundsätzlich versuche ich zu sagen, dass es nicht möglich ist mit MQTT – hardillb

+0

oh nein! ... naja ich schätze meine einzige Option ist die behaltene Nachricht und lwt, aber ich weiß nicht, wie ich das Problem überwinden werde, zumindest Abonnenten gleichzeitig zu vermeiden: /. Weißt du, wo ich eine kleine Implementierung finden kann, die die beibehaltene Nachricht verwendet, las ich in der hivemq.com, aber ich konnte – andreahg

Verwandte Themen