Zamieszanie na temat nawiązywania połączenia klient-serwer w MQTT

Zgodnie ze specyfikacjami zawsze klient powinien ustanowić połączenie z serwerem.

Klient:

Program lub urządzenie korzystające z MQTT. Klient zawsze ustanawia połączenie sieciowe z serwerem . To może

• Publikuj komunikaty aplikacji, którymi mogą interesować się inni klienci.

• Zasubskrybuj, aby poprosić o przesłanie komunikatów aplikacji, które jest zainteresowany

• Anuluj subskrypcję, aby usunąć żądanie wiadomości aplikacji.

• Odłącz od serwera.

A jeśli ten klient subskrybuje komunikat aplikacji, serwer powinien przekazać te komunikaty do tego konkretnego klienta.

Serwer:

Program lub urządzenie, które działa jako pośrednik między klientami publikującymi komunikaty aplikacji i klientami, którzy dokonali subskrypcji. Serwer

• Akceptuje połączenia sieciowe od klientów.

• Akceptuje komunikaty aplikacji publikowane przez klientów.

• Procesy Subskrybuj i anuluj subskrypcje żądań od klientów.

• Przekazuje komunikaty aplikacji pasujące do subskrypcji klienta .

Czy to oznacza, że ​​jeśli klient subskrybuje, to pozostaje podłączony do serwera, dopóki subskrypcja jest ważna, mimo że przez większość czasu nie ma przepływu danych?

Doszedłem do tego wniosku, ponieważ jeśli klient rozłączy się po subskrypcji, to serwer nie może przekazywać do niego wiadomości, ponieważ to klient powinien ustanowić połączenie. Ale nie będzie wiedział, kiedy to przywrócić.

Czy to oznacza, że ​​jeśli klient subskrybuje, to pozostaje podłączony do serwera, dopóki subskrypcja jest ważna, mimo że przez większość czasu nie ma przepływu danych?

Tak, po nawiązaniu połączenia klient będzie czekał na wiadomości, jednak będzie również regularnie wysyłać wiadomości PING do serwera w oparciu o wartość podtrzymania. Jeśli serwer PING nie otrzyma wiadomości PING, może się on odłączyć.

jeśli klient rozłączy się po subskrypcji, serwer nie może przesłać do niego wiadomości, ponieważ to klient powinien ustanowić połączenie.

Jeśli klient zostanie rozłączony, to tak, nie będzie otrzymywać wiadomości, jednak w MQTT istnieją funkcje, które działają w ten sposób.

Jeśli klient łączy się z serwerem z flagą „Wyczyść sesję” ustawioną na wartość false, serwer zapamięta subskrypcję tego identyfikatora klienta. Gdy klient ponownie się połączy, nie będzie musiał ponownie się subskrybować, ponieważ serwer go zapamięta.

Co więcej, możesz subskrybować, używając Poziomu 1 lub 2. QoS. Dzięki tym Poziomom QoS Serwer będzie przechowywać wiadomości i czekać na ponowne połączenie klienta przed wysłaniem. W ten sposób, nawet jeśli klient rozłączy się i ponownie połączy, nadal będzie otrzymywać wszystkie opublikowane wiadomości.

Ta strona ma dobre zasoby wyjaśniające protokół MQTT.

Czy to oznacza, że ​​jeśli klient subskrybuje, to pozostaje podłączony do serwera, dopóki subskrypcja jest ważna, mimo że przez większość czasu nie ma przepływu danych?

Tak, twój klient będzie czekał na wiadomości.

... jeśli Klient rozłączy się po subskrypcji, serwer nie może przekazywać wiadomości

Musisz zarządzać rozłączaniem (szczególnie w urządzeniach zasilanych bateryjnie). Można tego dokonać za pomocą funkcji „ testamentu i testamentu ” MQTT: gdy urządzenie się rozłączy, wyśle ​​ostatnią wiadomość.

Powinieneś rozróżnić połączenie i sesję.

Wszystko jest określone przez sesję. Gdy połączenie MQTT jest autoryzowane po raz pierwszy dla brokera, broker tworzy sesję dla tego połączenia, zwykle na podstawie parametru połączenia identyfikator-klienta.

W protokole MQTT 3.1.1 (domyślnie obecnie u większości klientów / brokerów) podczas połączenia możesz podać flagę clean = true lub clean = false. Jeśli clean = true, broker automatycznie utworzy nową sesję i zamknie ją, gdy połączenie zostanie zerwane / zamknięte. Jeśli clean = false, broker będzie utrzymywał sesję i dostarczał tam zdarzenia (do pewnego rodzaju pamięci sesji), nawet gdy klient zostanie odłączony. Zależy od implementacji brokerów, czy w ogóle pozwala ona na sesję clean = false i jakie jest maksymalne ttl takiej sesji.

W protokole MQTT 5.0 (bardzo świeży, ale perspektywiczny) można określić sesję ttl od strony klienta, a nawet zmienić ją po nawiązaniu połączenia. Jest to niezwykle przydatne w przypadku niestabilnych połączeń WAN (głównie IoT) lub stanowych połączeń, jak opisano.

AFAIK obecnie MQTT 5.0 protokołu z punktu widzenia klienta, może być stosowany w Pythonie z gmqtt w JavaScript z mqtt.js .