Pourquoi la sémantique est-elle une fois irréalisable?

Question

Dans la sémantique RPC où Erlang espère le meilleur, SUN RPC avec au moins une fois et Java RMI avec au plus une fois mais personne n’a exactement la même sémantique.

Pourquoi semble-t-il impossible de posséder une sémantique exactement une fois?

Par exemple, si le client continue de renvoyer une demande étiquetée de manière unique jusqu'à ce qu'une réponse soit reçue et qu'un serveur garde une trace de toutes les demandes traitées afin de ne pas dupliquer une demande. Ne serait-ce pas exactement une fois?

Answer 1

Considérez ce qui se passe si le serveur se bloque entre l'exécution de la requête et l'enregistrement de son exécution.

Vous pouvez obtenir au maximum une fois en enregistrant la demande, puis en l'exécutant. si vous obtenez un plantage entre les deux, alors vous l'avez enregistré (à tort) comme exécuté, vous ne le ferez plus. Donc au plus une fois

Bizarrement, celui-ci (avec des délais d'attente) est breveté: http://www.freepatentsonline.com/7162512 .html . Sauf ce que je dis ci-dessus, cela ne garantit pas exactement une fois.

Vous obtenez au moins une fois en l'exécutant, puis en l'enregistrant. Si vous rencontrez un blocage entre les deux, vous le répéterez si la demande est répétée.

Mais ce n'est pas vraiment faisable de dire "exactement une fois" en toutes circonstances

(Il existe des scénarios similaires pour les erreurs réseau plutôt que pour les pannes de serveur)

Answer 2

Des bus de messagerie haut de gamme, tels que WebSphere MQ ne prétend offrir une livraison qu'une seule fois. En fait, c'est le comportement par défaut (depuis la dernière fois que j'ai utilisé WMQ ...). Ils y parviennent grâce aux journaux d'écriture anticipée et à diverses techniques de verrouillage.

Bien sûr, je ne doute pas que cela soit enterré quelque part dans leurs documents juridiques, "exactement une fois". est en fait défini comme signifiant que le message peut ou ne peut pas être remis, une fois, plusieurs fois. Ou beaucoup. Ou moins de zéro. & Quot; afin de couvrir leur dos, mais cela fonctionne dans la grande majorité des cas, y compris le débranchement des câbles d’alimentation, l’acheminement des axes vers l’infrastructure réseau, etc.

Answer 3

Je pense que la réponse est qu'il vous faudrait un temps indéfini pour obtenir ces sémantiques, car le client devrait attendre un résultat définitif du serveur, qui risque de ne jamais arriver. Cette exigence est irréalisable sur les réseaux réels.

Si le client cesse d'essayer (ou si le serveur tombe en panne pendant une période prolongée, soit avant de terminer la transaction, soit avant de signaler qu'elle est terminée, cela dépend de l'ordre dans lequel il effectue ces opérations), il est alors impossible de le client doit savoir si la demande a été reçue et traitée. Dans la pratique, les systèmes RPC peuvent par exemple vouloir respecter les délais d'attente TCP par défaut. Par conséquent, ils ne souhaitent pas attendre le succès ou l'échec définitif du serveur.

C'est une supposition cependant: je n'ai jamais conçu de protocole RPC.