Confusione sulla creazione di connessioni client-server in MQTT

Secondo le specifiche , è sempre il client a stabilire una connessione a un server.

Cliente:

Un programma o dispositivo che utilizza MQTT. Un client stabilisce sempre la connessione di rete al server . Può

• Pubblica messaggi applicativi che potrebbero interessare altri clienti.

• Iscriviti per richiedere i messaggi applicativi che è interessato a ricevere.

• Annulla l'iscrizione per rimuovere una richiesta per i messaggi dell'applicazione.

• Disconnettersi dal server.

E se questo client si iscrive per un messaggio applicativo, il server dovrebbe inoltrare quei messaggi a questo particolare client.

Server:

Un programma o dispositivo che funge da intermediario tra i clienti che pubblicano messaggi applicativi e i clienti che hanno sottoscritto abbonamenti. Un server

• Accetta connessioni di rete dai clienti.

• Accetta i messaggi applicativi pubblicati dai clienti.

• Processi Sottoscrivi e annulla l'iscrizione alle richieste dei clienti.

• Inoltra i messaggi dell'applicazione che corrispondono agli abbonamenti client .

Questo significa che se un client si abbona, rimane connesso al server mentre l'abbonamento è valido anche se non ci sono flussi di dati nella maggior parte del tempo?

Vengo a questa conclusione perché se il client si disconnette dopo la sottoscrizione, un server non può inoltrare i messaggi perché è il client che deve stabilire una connessione. Ma non saprà quando ripristinarlo.

Questo significa che se un client si abbona, rimane connesso al server mentre l'abbonamento è valido anche se non ci sono flussi di dati nella maggior parte del tempo?

Sì, una volta stabilita la connessione il client attenderà i messaggi, tuttavia invierà anche messaggi PING al server in base al valore keepalive. Se un messaggio PING non viene ricevuto dal server, potrebbe disconnettersi.

se il client si disconnette dopo la sottoscrizione, un server non può inoltrare messaggi a esso perché è il client che deve stabilire la conenction.

Se il client è disconnesso, allora sì, non riceverà messaggi, tuttavia ci sono funzionalità in MQTT che aggirano questo.

Se il client si connette al server con il flag "Pulisci sessione" impostato su false, il server ricorderà l'abbonamento per quell'ID client. Una volta che il client si riconnette, non sarà necessario ripetere la sottoscrizione poiché il server lo avrà ricordato.

Inoltre, è possibile abbonarsi utilizzando QoS Level 1 o 2. Con questi livelli QoS, il server memorizzerà i messaggi e attenderà che il client si riconnetta prima di inviarli. In questo modo, anche se il client si disconnette e si riconnette, riceverà comunque tutti i messaggi pubblicati.

Questo sito ha alcune buone risorse che spiegano il protocollo MQTT.

Questo significa che se un client si abbona, rimane connesso al server mentre l'abbonamento è valido anche se non ci sono flussi di dati nella maggior parte del tempo?

Sì, il tuo client attenderà i messaggi.

... se il client si disconnette dopo la sottoscrizione, un server non può inoltrare i messaggi

Devi gestire la disconnessione (specialmente nei dispositivi alimentati a batteria). Questo può essere fatto usando la funzione " last will and testament " di MQTT: quando un dispositivo si disconnette, invierà un ultimo messaggio.

È necessario differenziare la connessione e la sessione.

Tutto è definito dalla sessione. Quando la connessione MQTT viene autorizzata per la prima volta al broker, il broker crea la sessione per questa connessione, in genere in base al parametro di connessione ID client.

Nel protocollo MQTT 3.1.1 (impostazione predefinita attualmente nella maggior parte dei client / broker) durante la connessione è possibile specificare clean = true o clean = false flag. Se clean = true, il broker creerà automaticamente una nuova sessione e la chiuderà quando la connessione viene interrotta / chiusa. Se clean = false, il broker manterrà la sessione e recapiterà lì gli eventi (in una sorta di archivio di sessione) anche quando il client è disconnesso. Dipende dall'implementazione dei broker se consente affatto clean = false session e qual è il massimo ttl di tale sessione.

Nel protocollo MQTT 5.0 (molto recente, ma prospettico) è possibile specificare la sessione ttl dal lato client o anche cambiarla dopo aver effettuato la connessione. Ciò è estremamente utile per connessioni WAN instabili (principalmente IoT) o connessioni stateful come descritto.

Per quanto ne so attualmente MQTT 5,0 protocollo dal punto di vista del cliente può essere utilizzato in pitone con gmqtt e in javascript con mqtt.js .