Perché la semantica è esattamente una volta impossibile?

Question

Nella semantica RPC dove Erlang ha la speranza per il meglio, SUN RPC con almeno una volta e Java RMI con quasi una volta, ma nessuno ha esattamente una semantica una volta.

Perché sembra impossibile avere esattamente una semantica?

Ad esempio se il client continua a inviare nuovamente una richiesta con tag univoci fino a quando non viene ricevuta una risposta e un server tiene traccia di tutte le richieste gestite per non duplicare una richiesta. Non sarebbe esattamente una volta?

Answer 1

Considerare cosa succede se il server si arresta in modo anomalo tra l'esecuzione della richiesta e la registrazione che ha eseguito la richiesta?

Puoi ottenere al massimo una volta registrando la richiesta, quindi eseguendola. se si verifica un arresto anomalo tra i due, l'hai (erroneamente) registrato come eseguito, quindi non lo farai più. Quindi al massimo

Stranamente, questo (con timeout) è brevettato: http://www.freepatentsonline.com/7162512 .html . Tranne quanto sopra, non garantisce esattamente una volta.

Ottieni almeno una volta eseguendolo, quindi registrandolo. Se si verifica un arresto anomalo tra i due, lo eseguirai nuovamente se la richiesta viene ripetuta.

Ma non è davvero possibile dire "esattamente una volta" in ogni caso

(Esistono scenari simili per errori di rete piuttosto che arresti anomali del server)

Answer 2

Bus di messaggistica di fascia alta, come WebSphere MQ pretende di offrire esattamente una volta consegnata. In realtà, questo è il comportamento predefinito (dall'ultima volta che ho usato WMQ ...). Ci riescono con Registri write-ahead e una varietà di tecniche di blocco.

Naturalmente, non dubito che sia sepolto da qualche parte nei loro documenti legali, "esattamente una volta". è in realtà definito come "il messaggio può o non può essere recapitato, una volta, più di una volta. O molti. O meno di zero. & Quot; al fine di coprire le loro spalle, ma funziona nella stragrande maggioranza dei casi, tra cui l'eliminazione dei cavi di alimentazione, l'asse degli assi verso l'infrastruttura di rete, ecc.

Answer 3

Penso che la risposta sia che avresti bisogno di una quantità indefinita di tempo per ottenere quella semantica, perché il client dovrebbe aspettare un risultato definitivo dal server, che potrebbe non arrivare mai. Tale requisito non è pratico su reti reali.

Se il client smette mai di provare (o se il server si arresta per un periodo prolungato o prima di completare la transazione, o prima di segnalare che è completo, a seconda dell'ordine che fa quelle cose), allora potrebbe non esserci alcun modo per il cliente deve sapere se la richiesta è stata ricevuta e gestita. In pratica, ad esempio, i sistemi RPC potrebbero voler rispettare i timeout TCP predefiniti, quindi non si deve aspettare un esito positivo o negativo dal server.

Questa è un'ipotesi: non ho mai progettato un protocollo RPC.