¿Por qué exactamente una vez la semántica no es factible?

Question

En la semántica de RPC donde Erlang tiene la esperanza de lo mejor, SUN RPC con al menos una vez y Java RMI con más de una vez, pero nadie tiene exactamente una vez la semántica.

¿Por qué parece imposible tener una semántica exactamente una vez?

Por ejemplo, si el cliente sigue reenviando una solicitud etiquetada de forma única hasta que se recibe una respuesta y un servidor realiza un seguimiento de todas las solicitudes manejadas para no duplicar una solicitud. ¿No sería eso exactamente una vez?

Answer 1

¿Considera lo que sucede si el servidor falla entre la ejecución de la solicitud y el registro de que ha realizado la solicitud?

Puede obtener, como máximo, una vez registrando la solicitud y luego ejecutándola. Si se produce un choque entre los dos, entonces (erróneamente) lo ha registrado como realizado, por lo que no lo volverá a hacer. Por lo tanto, a lo sumo una vez

Extrañamente, este (con tiempos de espera) está patentado: http://www.freepatentsonline.com/7162512 .html . Excepto por lo que sostengo anteriormente, no garantiza exactamente una vez.

Se obtiene al menos una vez ejecutándolo y luego grabándolo. Si se produce un bloqueo entre los dos, lo volverá a realizar si se repite la solicitud.

Pero no es realmente factible decir " exactamente una vez " en cualquier circunstancia

(Hay escenarios similares para errores de red en lugar de fallos del servidor)

Answer 2

Buses de mensajería de alta calidad, como WebSphere MQ significa ofrecer una entrega exactamente una vez. De hecho, este es el comportamiento predeterminado (desde la última vez que usé WMQ ...). Logran esto con Registros de escritura anticipada y una variedad de técnicas de bloqueo.

Por supuesto, no dudo que esté enterrado en algún lugar en sus documentos legales, "exactamente una vez" en realidad se define para significar que "el mensaje puede o no puede ser entregado, una vez, más de una vez. O mucho O menos que cero. & Quot; con el fin de cubrir sus espaldas, pero funciona en la gran mayoría de los casos, incluso desconectar los cables de alimentación, llevar los ejes a la infraestructura de red, etc.

Answer 3

Creo que la respuesta es que necesitarías una cantidad de tiempo indefinida para obtener esas semánticas, porque el cliente tendría que esperar un resultado definitivo del servidor, que tal vez nunca llegue. Ese requisito no es práctico en redes reales.

Si el cliente deja de intentarlo (o si el servidor deja de funcionar por un período prolongado, ya sea antes de completar la transacción o antes de indicar que está completa, según el orden en el que haga esas cosas), es posible que no haya forma de hacerlo. El cliente debe saber si la solicitud fue recibida y manejada. En la práctica, los sistemas RPC pueden, por ejemplo, querer respetar los tiempos de espera de TCP predeterminados, por lo que no quieren tener que esperar un éxito o fallo definitivo del servidor.

Aunque es una suposición: nunca he diseñado un protocolo RPC.