Torniamo a discutere le caratteristiche del protocollo di transactional messaging (T-Msg) affrontando in questo post le modalità con cui il protocollo gestisce i fault che si possono verificare nel sistema di agenti durante la fase di REQUEST (o fase REQ). I casi che si possono verificare sono i seguenti:
-
Il sender invia il messaggio SEND ed ed il nodo che lo ospita cade prima di aver ricevuto tutti gli ACK.
-
Il nodo che ospita il receiver cade prima di avere ricevuto il SEND o inviato l’ACK.
-
I messaggi di SEND o l’ACK sono persi nella rete;
Il primo dei problemi descritti è risolto semplicemente eseguendo la verifica dello stato dei messaggi inviati in fase di startup del nodo. In questo modo, infatti, il sender verificherà che il SEND inviato al secondo agent non ha avuto ancora l’ACK di conferma ricezione e provvederà ad inviare nuovamente messaggio.
Il secondo ed il terzo caso sono risolti attraverso l’uso di un timer interno che il mittente avvierà al momento dell’invio del messaggio SEND. Se il timer va in time out prima di aver ricevuto tutti gli ACK, il mittente non dovrà fare altro che ritrasmettere il messaggio ai destinatari che non hanno risposto.
Il timer dovrà essere impostato ad un valore determinato in modo casuale tra due possibili intervalli Tmin e Tmax. La scelta di tali valori influenza significativamente le performance del protocollo, infatti se troppo grandi si rischia di impiegare molto tempo a completare la fase di REQUEST, mentre se molto piccoli si potrebbero avere frequenti ritrasmissioni, anche non necessarie, con un conseguente aumento del traffico.
Concludiamo la trattazione dei fault in fase di REQ mostrando il diagramma degli stati relativi al sender e receiver relativamente alla trattazione del messaggio Mi.