Resumen

  • David Cheriton describió en el RFC 1045, de febrero de 1988, el protocolo experimental VMTP para transacciones de petición y respuesta. Un cliente, un número de transacción de 32 bits y el contador de reenvíos identificaban cada intento; el servidor conservaba estado para detectar duplicados.
  • Si la respuesta se declaraba idempotente, el cliente repetía la petición perdida y el servidor producía una respuesta nueva. Para una respuesta que debía conservarse, guardaba una copia o esperaba la confirmación. Una consulta de hora podía ganar frescura con el segundo intento.

El coste de un paquete perdido depende del momento en que desaparece. Si se pierde la petición, el servidor puede seguir esperando. Si se pierde la respuesta, el trabajo puede estar hecho y el cliente no saberlo. El RFC 1045 convirtió ese segundo caso en una elección explícita del Versatile Message Transaction Protocol. David Cheriton lo diseñó para intercambios de petición y respuesta, como las llamadas a procedimientos remotos, sobre datagramas poco fiables. Reenviar podía recuperar un mensaje o hacer trabajar otra vez a la aplicación. La red presentaba la factura; el tipo de operación decidía quién la pagaba.

Para saber qué factura correspondía, VMTP llevaba un registro. En un dominio de entidades, una transacción quedaba identificada por Cliente, Transaction y ForwardCount. El número de Transaction, de 32 bits, arrancaba con un valor aleatorio al crear el cliente y normalmente aumentaba tras cada intercambio. ForwardCount, de cuatro bits, permanecía en cero salvo cuando la petición pasaba a otro servidor. El servidor mantenía estado por cliente y descartaba como duplicado otro pedido con las mismas coordenadas. La oficina de reintentos necesitaba reconocer al visitante antes de darle una segunda ficha.

Ese reconocimiento tenía fecha de caducidad. El servidor retenía el estado un tiempo después de contestar, para que una copia tardía de la petición no reabriera el expediente. Si no conservaba estado, podía consultar al gestor del cliente con Probe; podía deducir que la petición era nueva si había retenido registros durante toda la vida posible de los paquetes más la ventana de reintentos y seguía sin reiniciar; o podía volver a hacer una operación conocida como segura de repetir. El botón «intentar otra vez» tenía detrás un pequeño departamento de archivos.

En una de las dos ventanillas, la respuesta llevaba la marca idempotente. VMTP no guardaba la contestación anterior. El cliente reenviaba la petición y el servidor la entregaba otra vez a la aplicación, que rehacía el trabajo y generaba otra respuesta. Solo la última transacción de ese cliente podía seguir ese camino; las peticiones viejas que llegaban tarde se descartaban. Cheriton escogió un ejemplo perfecto: si alguien pide la hora actual, volver a mirar el reloj puede dar mejor información que encontrar el papel de hace un minuto.

La otra ventanilla custodiaba el resultado. Si la respuesta no era idempotente, el módulo debía mantener una copia, incluso mediante copia al escribir, o retener al servidor hasta recibir confirmación. Aquí el coste era memoria o espera. Repetir una lectura del reloj refresca un dato; repetir una operación que modifica una cuenta puede cambiarla por segunda vez. La etiqueta de idempotencia expresaba una propiedad del trabajo, no una preferencia estética por paquetes más ligeros.

VMTP afinaba también los gastos pequeños: en condiciones de poca pérdida, una retransmisión podía llevar solo el bloque de control y pedir después los datos de segmento que faltasen. Una petición posterior podía dar por cerradas respuestas anteriores en la contabilidad del protocolo. Así, el diseño negociaba memoria, ancho de banda y tiempo de ejecución al mismo tiempo. El servidor no necesitaba archivar cada respuesta para siempre; tampoco podía tratar todos los trabajos como si fueran consultas al reloj.

El chiste del archivero demasiado aplicado tiene un límite claro. Guardar impecablemente la hora antigua puede ser peor que preguntarla de nuevo. Pero volver a ejecutar una instrucción con efectos reales exige saber exactamente qué se repite. VMTP organizó identificadores, memoria y descarte de duplicados alrededor de esa decisión. La aplicación debía aportar la parte más difícil: conocer el significado de su propia operación.