Resumen

  • Con la bandera SO, RFC 916 indicaba una carga de exactamente un octeto; el campo LENGTH ya no tenía que contarla, así que contenía el carácter y quedaba protegido por la suma de comprobación de la cabecera.
  • Durante SYN, esa misma posición anunciaba el Maximum Data Length del receptor; en un paquete común contaba datos; con SO era el dato. Las banderas válidas y el estado autorizaban la lectura.
  • Un bit de secuencia y otro de acuse bastaban sólo porque cada dirección permitía como máximo un paquete pendiente de respuesta. La sencillez imponía también un techo de rendimiento.

La RFC 916, publicada en octubre de 1984, propuso el Reliable Asynchronous Transfer Protocol, RATP. Estaba pensado para un enlace punto a punto, dúplex completo y normalmente RS-232 asíncrono: ordenadores personales, módems y dispositivos con microprocesadores que recibían órdenes. El registro del RFC Editor lo clasifica hoy como Historic. Esa categoría archivística no demuestra ni éxito ni fracaso de despliegue.

El texto ordenó sus prioridades: primero fiabilidad, después facilidad de implementación. Omitió la gestión dinámica de ventanas y varios paquetes simultáneamente pendientes. Si el extremo remoto cerraba, los datos aún en cola se descartaban; la especificación aceptó esa pérdida para eliminar dos estados. No pretendía reproducir toda la amplitud de TCP. Definía un mecanismo menor para una situación menor.

El receptor declaraba su límite al abrir

Cada paquete empezaba con una cabecera de cuatro octetos: líder de sincronización hexadecimal 01, control, longitud y suma de comprobación de cabecera. En un paquete SYN, sin embargo, la posición denominada longitud no medía datos. Contenía el Maximum Data Length, MDL: el máximo que quien enviaba ese SYN estaba dispuesto a consumir en un paquete recibido.

La apertura de tres pasos permitía que ambos extremos anunciaran su propio valor. Uno podía escoger un límite pequeño por memoria, controlador, velocidad o comportamiento del enlace. Incluso podía anunciar cero si no quería recibir datos, haciendo posible un uso unidireccional; los dos no podían elegir cero si pretendían intercambiar información.

El MDL tenía efecto, no sólo valor documental. Si llegaba una cabecera válida cuya longitud ordinaria superaba el máximo del receptor, RFC 916 lo trataba como infracción del protocolo o como una improbable corrupción no detectada. El receptor reiniciaba la conexión. La máquina que soportaba el coste fijaba la frontera y el par debía respetarla.

El máximo representable era 255. De ahí surgía una cota completa de 261 octetos para el paquete ordinario: sincronización, cabecera, suma de datos y hasta 255 octetos útiles. La especificación podía afirmar que no era necesario reservar más para una recepción individual. Una cifra de protocolo se convertía en una propiedad verificable de implementación.

Cuando la longitud pasó a ser el carácter

Tras abrir la conexión, y sin SYN, RST ni FIN, el mismo octeto se llamaba LENGTH. Normalmente indicaba cuántos datos seguían, de cero al MDL comunicado por el otro extremo. La transmisión interactiva de una sola pulsación, sin embargo, exponía mucho sobrecoste.

En el formato corriente, un carácter necesitaba cuatro octetos de cabecera, el carácter y dos octetos de suma de comprobación de datos: siete. Esperar más caracteres ahorraría cabeceras pero añadiría latencia perceptible.

La bandera SO, Single Octet, hizo que el número uno fuera implícito. Si estaba activa y las banderas incompatibles estaban a cero, LENGTH contenía el carácter, no una cuenta. No se enviaban la parte de datos ni su suma de dieciséis bits. La suma de la cabecera cubría el carácter incrustado. El documento llamó a la reducción de siete a cuatro octetos una mejora de eficiencia del 40 por ciento.

No hubo compresión estadística ni un nuevo alfabeto. El estado ya respondía tres preguntas: la cantidad era una, el dato estaba en una posición fija y su integridad limitada se comprobaba con la cabecera. Quitar esos elementos fuera de ese caso produciría ambigüedad, no eficiencia.

La posición no contenía su propia explicación

La tercera posición física tenía así tres contratos. En SYN era la capacidad del receptor que lo enviaba. Sin SO era una cuenta. Con SO era contenido. Un valor como 65 no revelaba por sí mismo si el extremo anunciaba una capacidad de 65, esperaba 65 octetos posteriores o enviaba el carácter correspondiente.

Primero había que reconocer la sincronización, validar control, posición y suma de cabecera, y comprobar que las banderas eran legales para el estado de la conexión. Sólo después existía una interpretación. El paquete no se explicaba de forma aislada; el estado aceptado era parte de su gramática.

Esto distingue el mecanismo del reúso de campos de BOOTP por DHCP. Allí una opción de sobrecarga autoriza interpretar zonas heredadas como secuencias de opciones y unas reglas ensamblan valores entre campos. Aquí una bandera por paquete elimina una longitud conocida, coloca el único dato en su hueco y cambia qué suma lo protege. Ambos hacen visible el cambio de lectura, pero no resuelven el mismo problema.

Un bit funcionaba porque no había una segunda duda

Los números SN y AN tenían un bit cada uno. La razón no era que dos valores bastaran para cualquier transporte fiable. RATP permitía como máximo un paquete pendiente de envío o acuse en cada dirección.

El receptor esperaba el siguiente valor módulo dos. Si veía el otro cuando correspondía el primero, podía reconocer un duplicado del paquete ya aceptado, probablemente retransmitido por pérdida del acuse. El emisor usaba AN para retirar de la cola su único paquete pertinente y alternar el bit.

Un acuse sin datos ni banderas de estado no exigía otro acuse. Eso evitaba una cadena infinita. Las direcciones seguían funcionando de forma independiente y podían combinar un acuse con datos cuando coincidían.

El límite de un paquete reducía buffers y estados, pero hacía imposible llenar una ruta durante la espera de ida y vuelta. En enlaces lentos, interactivos y con equipos modestos, la elección podía ser razonable. En una ruta con mayor producto ancho de banda-retardo, restringiría el caudal. El bit corto heredaba tanto la ventaja como el coste de la ventana inexistente.

El final del paquete no decidía el final superior

RATP separaba un flujo de octetos en paquetes. Usaba 01 para localizar el comienzo, pero no un delimitador final equivalente, porque cualquier patrón podía aparecer en los datos. Una cabecera aprobada decía cuántos octetos quedaban.

Un protocolo superior podía entregar una unidad mayor que el MDL. La bandera EOR decía que en ese paquete terminaba el registro superior; era responsabilidad de esa capa fijarla durante la fragmentación. Recibir y acusar un paquete no probaba haber reunido el registro completo.

La jerarquía de pruebas es concreta. La suma de cabecera limita la confianza en su lectura. La suma de datos, cuando existe, limita la confianza en la carga. SN y AN muestran una transición RATP. EOR ayuda al ensamblado. La aplicación todavía debe aceptar el objeto, y otra capa debe identificar y autorizar a quien ordena una acción.

Sincronizar tras el ruido era una decisión separada

RS-232 delimitaba octetos, no paquetes. El receptor buscaba el líder 01 y comprobaba los tres octetos siguientes. Si fallaba la suma, los volvía a tratar como entrada nueva mientras reanudaba la búsqueda. Una falsa coincidencia no justificaba saltar una cantidad desconocida del flujo.

La RFC 1055 documentó después SLIP con otra distribución de responsabilidades: delimitadores y escapes para datagramas IP, pero sin campo de tipo, máximo definido por el convenio básico ni corrección en el enlace. Las RFC 1661 y RFC 1662 describieron luego PPP, su multiplexación, LCP, límites variables, banderas, transparencia y FCS. Son comparaciones posteriores, no una línea genealógica demostrada.

La RFC 793 es la comparación contemporánea que RFC 916 citó al prescindir de una ventana dinámica. TCP abordaba un flujo fiable entre redes con un espacio de secuencia más amplio. RATP reunía datagrama, conexión fiable y enlace en un punto a punto. Compartir términos no convertía sus pruebas ni sus límites en equivalentes.

Estas fuentes no miden cuántas implementaciones de RATP existieron. Tampoco permiten decir que causó SLIP o PPP. Una suma de comprobación no autentica, no cifra y no autoriza. La enseñanza histórica es el contrato: se podían omitir bytes sólo cuando el estado compartido ya suministraba, sin adivinación, lo que esos bytes habrían dicho.