WebSphere MQ Telemetry Transport consegna i messaggi in base ai livelli definiti in un QoS (Quality of Service). I livelli sono descritti di seguito:
La seguente tabella mostra il flusso del protocollo di QoS livello 0.
Client | Messaggio e direzione | broker |
---|---|---|
QoS = 0 | PUBLISH |
Azione: pubblicare i messaggi per i sottoscrittori |
Un messaggio con QoS livello 1 ha un ID messaggio nell'intestazione del messaggio.
La seguente tabella mostra il flusso di protocollo di QoS livello 1.
Client | Messaggio e direzione | broker |
---|---|---|
QoS = 1 |
PUBLISH |
Azioni:
|
Azione: eliminare il messaggio | PUBACK |
Se il client non riceve un messaggio PUBACK (entro un periodo di tempo definito nell'applicazione o se si rileva un errore e la sessione di comunicazioni è riavviata), il client invia di nuovo il messaggio PUBLISH con l'indicatore DUP impostato.
Quando riceve un messaggio duplicato dal client, il broker ripubblica il messaggio per i sottoscrittori ed invia un altro messaggio PUBACK.
Un messaggio con QoS livello 2 ha un ID messaggio nell'intestazione del messaggio.
La seguente tabella mostra il flusso del protocollo di QoS livello 2.
Client | Messaggio e direzione | broker |
---|---|---|
QoS = 2 |
PUBLISH |
Azione: memorizzare il messaggio nel database |
PUBREC |
ID messaggio = x | |
ID messaggio = x | PUBREL |
Azioni:
|
Azione: eliminare il messaggio | PUBCOMP |
ID messaggio = x |
Se si rileva un errore o dopo un periodo di tempo definito, si ripete l'invio di ogni parte del flusso di protocollo con il bit DUP impostato. I flussi di protocollo aggiuntivi garantiscono che il messaggio sia consegnato ai sottoscrittori una sola volta.
Poiché QoS1 e QoS2 indicano che i messaggi devono essere consegnati, il broker memorizza i messaggi in un database. Se il broker ha problemi ad accedere a questi dati, i messaggi potrebbero andare perduti. Per ulteriori dettagli e per informazioni sulle azioni che si possono intraprendere per limitare questi problemi, consultare Progettazione delle applicazioni Telemetry.
In qualsiasi rete, è possibile che le unità o i link delle comunicazioni abbiano problemi di funzionamento. Se si verificano tali problemi, un'estremità del link potrebbe non essere a conoscenza di cosa stia accadendo all'altra estremità; si aprono delle finestre note come finestre in doubt. In questi scenari sono necessari dei presupposti sull'affidabilità delle unità e delle reti coinvolte nella consegna del messaggio.
WebSphere MQ Telemetry Transport presuppone che il client e il broker siano in genere affidabili e che il canale delle comunicazioni abbia più probabilità di essere inaffidabile. Se l'unità client ha esito negativo, si tratta in genere di un errore irreversibile, piuttosto che temporaneo. La possibilità di ripristinare i dati dall'unità è bassa. Alcune unità hanno memoria non volatile, ad esempio flash ROM. Fornendo una memoria più permanente all'unità client si proteggono i dati più importanti da alcune modalità di errore.
Se si va oltre il malfunzionamento di base del link delle comunicazioni, la matrice della modalità di errore diviene complessa, dando come risultato un numero di scenari superiore a quelli che la specifica per WebSphere MQ Telemetry Transport può gestire.
Il ritardo di tempo (intervallo nuovo tentativo) prima di inviare di nuovo un messaggio che non sia stato riconosciuto è specifico dell'applicazione e non è definito dalla specifica del protocollo.