networking - sociedad - Semántica de RPC cuál es exactamente el propósito

redes semanticas pdf

Question

Estaba pasando por la semántica rpc, semántica al menos una vez y casi una vez, ¿cómo funcionan?

No se pudo entender el concepto de su implementación.

Answer 1

En ambos casos, el objetivo es invocar la función una vez. Sin embargo, la diferencia está en sus modos de falla. En "al menos una vez", el sistema volverá a intentarlo en caso de fallo hasta que sepa que la función se invocó con éxito, mientras que "a lo más una vez" no intentará volver a intentarlo (o se asegurará de que haya un reconocimiento negativo del invocación antes de reintentar).

En cuanto a cómo se implementan, esto puede variar, pero el pseudocódigo podría verse así:

At least once:
request_received = false
while not request_received:
send RPC
wait for acknowledgement with timeout
if acknowledgment received and acknowledgement.is_successful:
request_received = true
At most once:
request_sent = false
while not request_sent:
send RPC
request_sent = true
wait for acknowledgement with timeout
if acknowledgment received and not acknowledgement.is_successful:
request_sent = false

Un caso de ejemplo en el que desea hacer "a lo más una vez" sería algo como pagos (no querría facturar accidentalmente dos veces la tarjeta de crédito de alguien), donde un caso de ejemplo de "al menos una vez" sería algo como actualizar una base de datos con un valor particular (si escribe el mismo valor dos veces seguidas en la base de datos, eso no tendrá ningún efecto en nada). Casi siempre desea utilizar "al menos una vez" para operaciones no mutantes (también conocidas como idempotent); por el contrario, la mayoría de las operaciones de mutación (o al menos las que mutan de forma incremental el estado y, por lo tanto, dependen del estado actual / anterior al aplicar la mutación) necesitarán "a lo sumo una vez".

Debo añadir que es bastante común implementar la semántica "a lo más una vez" en la parte superior de un sistema "al menos una vez" al incluir un identificador en el cuerpo del RPC que lo identifica de forma única y al garantizar en el servidor que cada ID se ve. Por el sistema se procesa una sola vez. Puede pensar en los números de secuencia en paquetes TCP (asegurándose de que los paquetes se entreguen una vez y en orden) como un caso especial de este patrón. Sin embargo, este enfoque puede ser un tanto difícil de implementar correctamente en sistemas distribuidos donde los reintentos del mismo RPC podrían llegar a dos computadoras separadas que ejecuten el mismo software de servidor. (Una técnica para lidiar con esto es registrar la transacción en la que se recibe el RPC, pero luego agregar y desduplicar estos registros utilizando un sistema centralizado antes de redistribuir las solicitudes dentro del sistema para su procesamiento posterior; otra técnica es procesar de manera oportunista el RPC, pero para reconciliar / restaurar / revertir el estado cuando la sincronización entre los servidores finalmente detecte esta duplicación ... este enfoque probablemente no funcionará para los pagos, pero puede ser útil en otras situaciones como las publicaciones en los foros).