Come viene risolto il problema del deadlock del messaggio nelle applicazioni del mondo reale?

In pratica lo risolvi in questo modo:

1. A invia X a B.
2. B invia un riconoscimento a A verificando che abbia ricevuto ciò che è stato inviato. (Per protocolli semplici come TCP restituisce un checksum, quelli più complessi come rsync potrebbero restituire un hash MD5.)
3. Se A non riesce a ricevere il riconoscimento in modo tempestivo, invia di nuovo X. In attenti protocolli mondiali (ad es. TCP) solitamente si fa con un ritardo variabile nel caso in cui il problema sia la congestione della rete.

Questo continua fino a quando A riceve un riconoscimento o rinuncia all'invio del messaggio.

In teoria potresti fare cose molto più complesse e affidabili. Tuttavia, è probabile che le ricerche in quest'area inducano la depressione. Vedi link per ottenere lo scherzo.

In teoria, questo problema non è risolvibile per singoli messaggi, e A e B non possono sapere per certo che un messaggio è stato ricevuto e riconosciuto. Vedi il Dilemma di due generali .

Se stai inviando una serie di messaggi, questo cambia leggermente. È possibile che sia il mittente sia il destinatario sappiano che alcuni messaggi sono stati inviati e ricevuti correttamente. Ad esempio, TCP / IP utilizza una strategia che include l'uso di numeri di sequenza. Ogni segmento contiene un numero di sequenza che viene rinviato nel riconoscimento. Questa disposizione sembra essere sufficiente per gestire una grande rete di dati mondiale.

Hai davvero bisogno di verificare che A sappia che B sa che A sa che B sa che A sa che B sa che A ha cambiato il valore di X?

B ha bisogno di sapere che A ha cambiato il valore di X. Questo è ovvio.

A deve sapere che B sa che A ha cambiato il valore di X, perché se B non ha ricevuto il messaggio A ha bisogno di rinviarlo. Questo non può essere evitato a meno che non si presuma che l'intera pipa di messaggistica sia perfetta e non possa perdere i messaggi.

Ma B deve sapere che A sa che B sa che A ha cambiato il valore di X? Si può dire che B ha bisogno di sapere quando interrompere l'invio di ACK, ma è davvero necessario? Io dico di no! Qui è dove si ferma la catena ACK!

B non ha bisogno di verificare che A abbia ottenuto l'ACK. Se A non ha ottenuto l'ACK, assumerà semplicemente che B non ha ricevuto il messaggio originale e lo invia di nuovo. B riceverà il messaggio resent e lo riconoscerà già ricevuto e non farà nulla o - se non è stato implementato il riconoscimento di tale duplicazione dei messaggi - sarà sufficiente impostare nuovamente il valore di X. Nessun danno fatto. In ogni caso, B invierà un ACK sul messaggio inviato nuovamente.

A è responsabile di assicurarsi che B ottenga il nuovo valore di X. A ha bisogno di inviare nuovamente il messaggio di nuovo e di nuovo - ma B ha solo bisogno di inviare un ACK per ogni messaggio di A.