Resumen

  • El maestro de MTP fijaba accepted, pending o rejected; aceptaba cuando había observado data[eom] y todos los paquetes intermedios del mensaje.
  • Un vector móvil conservaba los estados de los últimos doce mensajes, impedía expulsar una decisión pendiente y distribuía el acuerdo sin pedir una confirmación positiva a cada consumidor exitoso.
  • Ese acuerdo resolvía orden y recuperación de transporte sobre multicast de mejor esfuerzo; no demostraba interpretación de la aplicación, autorización, identidad autenticada ni resultado operativo.

La economía empezó por no responder

RFC 1112 daba a IP una forma de enviar un datagrama a un grupo dinámico. No prometía que el datagrama llegase intacto a todos sus miembros ni que mantuviese el orden relativo. MTP se colocó encima para ofrecer otra clase de disciplina: procesos admitidos, permiso para transmitir, números de mensaje, recuperación y una decisión común.

El conjunto se llamaba web. Un miembro era maestro; los demás podían producir y consumir o limitarse a consumir. El maestro gobernaba la membresía, los parámetros y los tokens de transmisión. Un productor necesitaba un token con número de mensaje antes de emitir datos ordinarios.

Pero la escala impedía pensar como una conversación entre dos extremos. MTP no esperaba un ACK positivo de cada consumidor. Usaba NAK: sólo quien detectaba una carencia pedía reparación. El silencio normal reducía tráfico inverso. Por ello, la ausencia de protesta era una pieza del algoritmo, no un recibo firmado por cada destino.

Aceptado describía lo que vio el maestro

La regla cabía en tres ramas. Si el maestro había visto el paquete con data[eom] y todo lo anterior del mismo mensaje, asignaba aceptado. Si faltaban partes pero consideraba al productor operativo y conectado, mantenía pendiente. Si faltaban partes y creía que el productor había fallado o quedado separado, asignaba rechazado.

La completitud se medía desde un observador privilegiado. La decisión era autoritativa para MTP porque el protocolo le había entregado esa competencia. No era una encuesta. Un consumidor podía aprender el estado en un paquete posterior sin haber enviado una declaración propia de éxito.

También había una frontera semántica. RFC 1301 trataba los datos del cliente como octetos no interpretados. El maestro reconocía comienzo, secuencia y fin; no validaba un documento ni ejecutaba una orden. Un mensaje completo podía ser inútil, inválido, duplicado o rechazado por la aplicación.

Doce estados formaban memoria, no archivo

Cada paquete llevaba un registro de aceptación. Un indicador señalaba si el cliente pedía sincronización y un vector de doce elementos, dos bits cada uno, describía aceptado, pendiente o rechazado para los mensajes anteriores. Al avanzar la secuencia, el vector se desplazaba. La historia vieja salía.

El límite de memoria tenía una salvaguarda contundente. El maestro no podía dejar que un pendiente cruzara el último puesto. Debía detener la confirmación de nuevos tokens hasta resolver el más antiguo como aceptado o rechazado. La incertidumbre bloqueaba progreso antes de ser borrada.

Esa decisión convertía una deuda de evidencia en presión operativa. Aun así, cuando un estado final se desplazaba fuera del vector, desaparecía de los encabezados nuevos. Quien necesitara auditoría duradera debía conservarlo aparte, junto con los paquetes y juicios que lo produjeron.

Los números de mensaje eran de 16 bits, iniciados e incrementados por el maestro al conceder tokens. Conceder uno consumía el número y exigía un desenlace final. Eso daba orden dentro de la instancia de transporte, no una identidad eterna para el acto de negocio.

Una confirmación repetida no decía qué se perdió

Los mensajes de control no usaban los números ordinarios, de modo que una segunda solicitud de token podía ser nueva o repetida. Quizá el productor nunca vio la confirmación. Quizá transmitió y el maestro no vio ninguno de sus paquetes. Quizá la solicitud posterior adelantó a una confirmación tardía.

RFC 1301 resolvía la ambigüedad con conducta, no con una falsa certeza. Mientras el token siguiera pendiente desde el maestro, podía reasignarlo. Si el productor recibía una confirmación duplicada, la interpretaba como un NAK y volvía a emitir los datos ligados a ese número. Si ya no necesitaba el permiso, enviaba empty[cancel].

Una captura debe conservar esas alternativas. La retransmisión prueba una reacción prevista ante incertidumbre; no prueba cuál de los paquetes anteriores se perdió.

Heartbeat, window y retention delimitaban la reparación

heartbeat daba el ritmo común. window limitaba los paquetes de datos, nuevos o retransmitidos, que un productor podía poner en el web durante un latido. retention fijaba cuántos latidos debía conservar datos y estado para responder a futuras pérdidas.

Cuando no había suficientes bytes para llenar un paquete y el mensaje continuaba abierto, el productor enviaba empty[dally]. Los mensajes breves se completaban con paquetes vacíos hasta alcanzar al menos la cantidad de retención. Repetir aumentaba la probabilidad de que los consumidores observaran un paquete e identificaran al productor. No garantizaba que todos lo hubieran hecho.

El consumidor detectaba un hueco por un salto de secuencia o por un fragmento sin final seguido de más de un latido de silencio. Su NAK unicast enumeraba rangos perdidos. El productor retransmitía esos datos por multicast a todo el web, daba prioridad a la reparación y descontaba esos paquetes de la ventana. Quienes ya los tenían debían ignorar duplicados.

Si el dato había vencido, nak[deny] convertía el límite de retención en un fallo explícito. El receptor debía informar a su cliente y podía retirarse. El protocolo sabía decir «ya no puedo reparar»; no podía reconstruir una aplicación que nunca guardó su propio recibo.

La dirección del grupo tampoco era identidad

Para operar sobre IP, MTP exigía el nivel 2 de RFC 1112 y usaba el grupo permanente 224.0.1.9. Un encabezado puente añadía puertos, longitud y checksum opcional bajo el número de protocolo IP 92. Los TSAP y los identificadores de conexión distinguían instancias y destinos.

Nada de eso autenticaba al miembro. RFC 1301 no discutía seguridad. Un proceso reconocido por la máquina de estados podía estar correctamente encaminado sin que su identidad organizativa, su autoridad o la integridad del intercambio hubieran sido demostradas.

La revisión posterior señaló el cuello de botella

RFC 1458 analizó MTP para grandes flujos de imágenes. Reconoció el control de orden mediante tokens, la recuperación selectiva por NAK y la obligación de tolerar duplicados. Al mismo tiempo señaló dependencias externas para direcciones e identificadores y el coste de hacer pasar casi todo el control por el maestro. Para esa carga, el retardo y la congestión lo volvían inadecuado.

La crítica no borraba la semántica. Añadía otra separación: una decisión puede ser correcta dentro de un protocolo y, aun así, la topología que la produce puede no servir a otra escala o carga.

Fuentes

Las fuentes describen protocolos y una evaluación histórica. No prueban una implantación MTP, una población real, miembros autenticados, procesamiento de aplicación, incidente, adopción ni resultado presente.