2009-01-06 26 views
10

En semántica RPC, donde Erlang tiene la esperanza de lo mejor, SUN RPC con al menos una vez y Java RMI con a lo sumo pero ninguna tiene exactamente una vez semántica.¿Por qué es exactamente una semántica imposible?

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

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

Respuesta

21

Considere lo que sucede si el servidor falla entre realizar la solicitud y registrar que ha llevado a cabo la solicitud.

Puede obtener a lo sumo una vez registrando la solicitud y luego realizándola. si consigues un choque entre los dos, entonces (erróneamente) lo registraste como llevado a cabo, por lo que no lo volverás 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 como argumento arriba, no garantiza exactamente una vez.

Obtiene al menos una vez llevándolo a cabo y luego registrándolo. Si consigues un choque entre los dos, lo llevarás a cabo nuevamente si la solicitud se repite.

Pero en realidad no es posible decir "exactamente una vez" en todas las circunstancias

(Hay escenarios similares para los errores de red en lugar de servidor se bloquea)

+1

Nota interesante sobre exactamente una vez: http: //ilpubs.stanford. edu: 8090/483/1/2000-7.pdf –

1

Creo que la respuesta es que se necesitaría una tiempo indefinido para obtener esa semántica, 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 alguna vez deja de intentarlo (o si el servidor deja de funcionar por un período prolongado antes de completar la transacción, o antes de indicar que está completo, dependiendo del orden en que lo haga) entonces no hay forma de hacerlo para que el cliente sepa 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 falla definitiva del servidor.

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

3

Los buses de mensajería de gama alta, como el WebSphere MQ de IBM, pretenden ofrecer exactamente una entrega. De hecho, este es el comportamiento predeterminado (como la última vez que utilicé WMQ ...). Lo logran con Write-ahead logs y una variedad de técnicas de bloqueo.

Por supuesto, no dudo que enterrado en algún lugar de sus documentos legales, "exactamente una vez" en realidad se define como "mensaje puede o no ser entregado, una vez, más de una vez. O lotes. cero." para cubrir sus espaldas, pero funciona en la gran mayoría de los casos, incluyendo expulsar cables de alimentación, llevar ejes a la infraestructura de red, etc.

+1

WebMethods Broker también tiene "exactamente una vez" en su material de marketing. – slim

+0

Esto seguramente tiene que ser "¿Todavía no se ha llevado a cabo o exactamente una vez"? Es decir. debe tener transacciones indefinidamente largas, o simplemente considere desactivar el servidor :) –

+0

Creo que puede obtener exactamente una vez la entrega de un mensaje si el paso de entrega final es atómico.Sin embargo, si hay un cálculo arbitario como parte del paso de "entrega" (como lo hay para RPC), no veo cómo hacer esto exactamente, una vez. –