Resumen

  • RFC 2188 separó explícitamente la ejecución de una operación, la entrega de su resultado, el acuse del invocador y las confirmaciones o fallos que cada extremo observa después. Una indicación local de fallo no constituye por sí sola una historia compartida de lo ocurrido.
  • ESRO ofrecía dos compromisos distintos: un modo de resultado reconocido, con tres pasos y conocimiento derivado del ACK, y otro no reconocido, con dos pasos y confirmaciones del ejecutor que sólo señalaban el fin local de la operación.
  • Los identificadores de invocación permiten correlacionar intercambios, pero no autentican al par, no vuelven idempotente una operación ni demuestran que una consecuencia empresarial haya quedado confirmada de manera durable.
  • La arquitectura deja decisiones decisivas fuera del protocolo: temporizadores, retransmisiones, autenticación, semántica de parámetros, idempotencia, commit y reconciliación pertenecen a capas diferentes y a responsables diferentes.

Dos extremos pueden contar historias distintas y decir la verdad

Imaginemos el caso con el que conviene leer RFC 2188. Un invocador pide una operación. El ejecutor la realiza con éxito y transmite un ESROS-RESULT. El invocador lo recibe, genera la indicación correspondiente para su usuario y envía el ACK previsto por el modo de resultado reconocido. Pero ese ACK desaparece en la red.

Desde el punto de vista del invocador, el resultado llegó. Desde el punto de vista del ejecutor, falta la evidencia que debía cerrar el intercambio. Tras agotar el mecanismo previsto, su proveedor puede producir una FAILURE.indication.

Ambos extremos han observado hechos reales. El problema aparece sólo cuando una aplicación, un operador o un registro posterior convierte una observación local en una afirmación universal: «la operación fracasó». RFC 2188 no concede esa conclusión.

En el modo reconocido, la confirmación de resultado o error del ejecutor llega después de recibir el ACK del invocador. Ésa es una diferencia crucial. La confirmación no equivale simplemente a «la aplicación terminó»; incorpora evidencia procedente del otro extremo. A la inversa, una indicación de fallo en el ejecutor puede corresponder a varias situaciones: se perdió el PDU de resultado o error, se perdió el ACK, o se produjo un fallo local del proveedor ESRO. Por eso el documento contempla que una aplicación recurra a una operación separada de verificación cuando necesite resolver la incertidumbre.

La arquitectura obliga así a distinguir entre lo que ocurrió y lo que un extremo puede demostrar que ocurrió.

ESRO no era una teoría general de RPC

RFC 2188 describía Efficient Short Remote Operations, ESRO, como un protocolo de operaciones remotas fiable y orientado a intercambios breves sobre UDP. El objetivo era reducir sobrecarga en entornos donde los costes de comunicación importaban especialmente, incluidos enlaces inalámbricos como CDPD.

No se trataba de volver UDP mágicamente equivalente a una sesión pesada. ESRO añadía mecanismos apropiados para su objetivo: segmentación y reensamblado, concatenación y separación de unidades y multiplexación de aplicaciones. Utilizaba el puerto UDP 259 y mantenía separados los papeles de invocador y ejecutor.

El documento es Informational, no un Internet Standard. Tampoco pasó por la revisión de un grupo de trabajo del IETF, y la información editorial asociada conserva una advertencia del IESG sobre escalabilidad. Esas condiciones importan porque sitúan el texto históricamente: especifica una propuesta concreta y sus reglas operativas, no una doctrina universal sobre todas las llamadas remotas.

Compararlo con la tradición más amplia de RPC puede ser útil para orientarse, pero diluye precisamente lo que RFC 2188 hace explícito. Su interés está en qué mensaje conoce cada extremo, qué confirmación depende de qué mensaje anterior y qué inferencias no están justificadas.

El primer corte: pedir no es entregar

La primera capa es la solicitud de invocación. La segunda es su entrega al ejecutor. Son cosas distintas.

Que una aplicación haya emitido una petición no demuestra que el otro extremo la haya recibido. Que el protocolo asigne o transporte un identificador de invocación tampoco demuestra ejecución. El identificador permite correlacionar mensajes pertenecientes a una operación; no convierte esa correlación en prueba de autenticidad ni de efecto.

Después viene otra frontera: recibir una invocación tampoco es lo mismo que haber realizado con éxito la acción pedida. La ejecución pertenece al ejecutor y puede concluir de forma satisfactoria o no. ESRO proporciona entonces formas de reportar esas dos posibilidades: ESROS-RESULT señala una operación realizada con éxito; ESROS-ERROR, una operación realizada sin éxito.

Ésa es información sobre la operación. No debe confundirse con los estados posteriores del intercambio de protocolo.

Resultado y confirmación responden a preguntas diferentes

Cuando el ejecutor construye un resultado, sabe algo sobre su propia ejecución. Cuando el resultado viaja por la red, aparece una pregunta distinta: ¿llegó?

En el modo reconocido de ESRO hay una tercera pregunta: ¿sabe el ejecutor que el invocador recibió suficiente información como para emitir el ACK?

Éste es el sentido del esquema de tres pasos. El resultado o error va del ejecutor al invocador; el ACK vuelve hacia el ejecutor. Sólo después de recibirlo se produce en el lado ejecutor la RESULT.confirm o ERROR.confirm.

Por tanto, la confirmación incorpora un grado de conocimiento que no estaba presente en el mero acto de enviar un resultado. No prueba todo lo que una aplicación moderna podría querer saber: no certifica una transacción empresarial posterior, no prueba almacenamiento durable en otro sistema y no garantiza que una consecuencia externa haya quedado reconciliada. Pero sí representa evidencia más fuerte sobre la recepción protocolaria que la simple transmisión.

RFC 2188 no colapsa esas capas. Nosotros tampoco deberíamos hacerlo.

El caso incómodo del FAILURE

La indicación de fallo del ejecutor en modo reconocido es deliberadamente menos concluyente de lo que muchos sistemas de registro desearían.

Si aparece después de enviar un resultado satisfactorio, puede significar que el resultado no llegó. Pero también puede significar que sí llegó y que se perdió el ACK. O puede reflejar un fallo del proveedor local.

La consecuencia lógica es incómoda pero limpia: el ejecutor puede carecer de prueba suficiente para distinguir esas historias.

Ese límite convierte en peligrosa cualquier regla que traduzca mecánicamente FAILURE como «el invocador no recibió el éxito». El documento sugiere una salida precisamente porque no pretende resolver por deducción lo que el intercambio ya no permite conocer: una operación adicional de verificación.

En el lado invocador, una indicación de fallo en modo reconocido implica también fallo en el lado ejecutor según el modelo del protocolo. Pero esa relación concreta no transforma ambos extremos en una sola máquina epistemológica. Las observaciones siguen siendo locales, con eventos y evidencias diferentes.

El segundo corte: ahorrar un ACK cambia lo que puede saberse

ESRO también define un modo no reconocido, de dos pasos. Aquí desaparece el ACK del invocador y, con él, la posibilidad de que el ejecutor obtenga esa clase de información procedente del par.

La diferencia no es meramente contar paquetes.

En este modo, RESULT.confirm y ERROR.confirm del ejecutor se generan sin información del otro extremo. Su significado protocolario se limita, por tanto, al fin local de la operación. No dicen que el invocador haya recibido el resultado o el error.

Tampoco se genera una FAILURE.indication del ejecutor por el protocolo en este modo. No hay un ACK cuya ausencia pueda utilizarse como parte del mecanismo de cierre.

El invocador, en cambio, aún puede experimentar fallo: puede no haber recibido resultado, error ni otra indicación esperada, o puede haber ocurrido un problema en su proveedor local. De nuevo, la semántica es relativa al observador.

El ahorro de un mensaje tiene así una consecuencia informativa. Menos handshake significa menos tráfico, pero también menos evidencia derivada del par.

La eficiencia era una elección de arquitectura, no una promesa gratis

RFC 2188 debe leerse como una especificación consciente del coste de cada garantía adicional. Un protocolo diseñado para operaciones breves y enlaces potencialmente costosos no puede tratar cada nueva confirmación como gratuita.

De ahí las dos modalidades. Si una aplicación necesita que el ejecutor obtenga evidencia derivada de la recepción por el invocador, el modo reconocido paga un paso adicional. Si basta con que el ejecutor termine localmente y no necesita esa evidencia del par, el modo no reconocido elimina el ACK.

La distinción parece pequeña vista desde una red contemporánea de gran ancho de banda. Sin embargo, el principio es más duradero: reducir mensajes puede reducir también el conocimiento disponible.

No es correcto describir uno de los modos como simplemente «fiable» y el otro como «no fiable». La pregunta útil es qué hecho necesita conocer cada extremo y qué mensaje produce esa evidencia.

Correlación no es autenticación

ESRO utiliza identificadores de invocación para relacionar mensajes con una operación. Ese mecanismo es esencial para distinguir intercambios, especialmente cuando existen retransmisiones o concurrencia.

Pero un identificador responde a «¿a qué operación pertenece este mensaje?», no a «¿quién es realmente el emisor?».

RFC 2188 no proporciona autenticación. La responsabilidad de autenticar recae en el ejecutor fuera de ESRO. Esto vuelve especialmente importante no ampliar el significado de un invoke ID hasta convertirlo en una credencial que nunca fue.

Tampoco el identificador garantiza idempotencia. Si una aplicación vuelve a ejecutar una acción con efectos secundarios, la existencia de un número de correlación no impide por sí sola duplicar esos efectos.

Y menos aún prueba un commit empresarial. Saber que cierto resultado pertenece a cierta invocación sigue siendo distinto de demostrar que una orden comercial quedó asentada, que un mensaje externo fue entregado una sola vez o que un sistema de registro persistió definitivamente el cambio.

Los parámetros pueden viajar sin que ESRO decida qué significan

La especificación permite asociar información sobre el tipo de codificación, pero deja fuera del alcance de ESRO la semántica de la codificación de los parámetros.

Ésta es otra frontera importante. El transporte y la operación remota pueden mover datos sin definir completamente la semántica de negocio que esos datos representan.

Por eso una cadena de inferencias como «ESRO aceptó el parámetro, luego la aplicación autorizó la acción, luego el efecto se comprometió durablemente» salta varias capas.

La codificación pertenece a una decisión de aplicación. La autorización pertenece a otra. La idempotencia y el tratamiento de reintentos, a otra más. El commit durable puede depender todavía de almacenamiento, sistemas externos o conciliación posterior.

Los temporizadores son política de despliegue

ESRO define un marco de retransmisión, pero no pretende que un conjunto universal de números sirva para todas las redes.

El desplegador elige intervalos de retransmisión, número máximo de retransmisiones, tiempo de inactividad y vida de los números de referencia de acuerdo con las características del entorno.

Eso significa que un timeout tampoco tiene semántica empresarial intrínseca. Un límite temporal refleja una combinación de configuración y condiciones observadas. Puede ser apropiado para una red y agresivo para otra. Puede agotarse por pérdida, retraso o fallo local sin revelar si un efecto externo ya sucedió.

El protocolo proporciona los mecanismos; la interpretación operacional depende de cómo fueron configurados.

Reintentar no equivale a deshacer la incertidumbre

La tentación natural ante un timeout es repetir la operación. En una acción puramente idempotente, esa estrategia puede ser aceptable. En una acción que produce un efecto irreversible o no idempotente, puede ser desastrosa.

Supongamos que el ejecutor realizó una acción, envió un resultado satisfactorio y el ACK se perdió. El ejecutor observa fallo. Si la aplicación interpreta ese fallo como prueba de que nada ocurrió y ejecuta de nuevo la acción, puede duplicar el efecto.

La incertidumbre protocolaria se convierte entonces en un problema de semántica de aplicación.

RFC 2188 no promete «exactly once». Tampoco presenta un identificador de invocación como solución completa a los reintentos. La forma segura de razonar exige distinguir la evidencia sobre mensajes de la evidencia sobre efectos.

Una operación de estado puede valer más que otra ejecución

La sugerencia de utilizar una operación separada de verificación merece más atención de la que suele recibir.

Cuando el intercambio principal deja dos historias compatibles con la evidencia, ejecutar otra vez la acción original mezcla recuperación con producción de un nuevo efecto. Preguntar por el estado, en cambio, puede resolver la incertidumbre sin repetir la acción.

Esta separación anticipa una disciplina útil: comando y verificación no tienen por qué ser la misma operación.

El comando intenta producir el cambio. La consulta posterior intenta establecer qué estado quedó. Si la aplicación utiliza además identificadores de negocio estables o reglas de idempotencia, puede reconciliar fallos de transporte sin convertir cada timeout en una nueva decisión irreversible.

Un resultado satisfactorio tampoco es el final de toda la historia

Incluso un ESROS-RESULT correctamente recibido sólo informa de la operación tal como la entiende el ejecutor. No autentica por sí solo a ese ejecutor. No demuestra que una acción posterior en un sistema externo haya quedado durablemente registrada. No demuestra que un pago, una entrega física o cualquier otro compromiso ajeno a ESRO haya alcanzado un estado final.

Esto no es una carencia particular de ESRO. Es la consecuencia de asignar responsabilidades por capas.

La contribución de RFC 2188 es ser explícito sobre dónde termina su propio conocimiento.

RFC 2524 muestra intención de uso, no prevalencia

RFC 2524 utilizó posteriormente ESRO como base para un protocolo eficiente de envío y entrega de correo. Eso proporciona evidencia histórica de un uso previsto de la arquitectura: operaciones relativamente compactas donde reducir sobrecarga era un objetivo real.

No demuestra, sin embargo, despliegue actual, predominio comercial ni éxito universal. Tampoco convierte RFC 2188 retrospectivamente en una solución general para cualquier sistema distribuido.

La relación entre ambos documentos sirve mejor como ejemplo de composición protocolaria: una capa posterior podía construir funciones concretas sobre ESRO manteniendo separadas las decisiones propias de la aplicación.

El legado útil está en las fronteras de evidencia

Leído hoy, RFC 2188 resulta interesante no porque ofrezca una receta para sistemas distribuidos contemporáneos, sino porque obliga a nombrar cada frontera.

Existe una solicitud de invocación. Existe su posible entrega. Existe la ejecución del ejecutor. Existe la construcción de un resultado o error. Existe su entrega. Existe una indicación al invocador. En el modo reconocido existe un ACK. Luego existen confirmaciones o fallos locales. Separadamente están la autenticación, la autorización, la idempotencia, el commit durable y la reconciliación.

Ninguna de esas capas prueba automáticamente todas las siguientes.

Esa frase resume mejor RFC 2188 que cualquier mito de «exactly once». El documento no elimina la incertidumbre; especifica dónde aparece y qué evidencia adicional cuesta reducirla.