Resumen

  • RFC 3081 asignó una sesión BEEP a una conexión TCP, pero no tomó el control de flujo de toda la conexión como garantía de progreso para sus canales multiplexados.
  • Cada canal comenzaba con 4096 octetos de crédito. Las tramas SEQ actualizaban ese límite local con prioridad y la recomendación round-robin impedía que un canal ocupado consumiera todos los turnos.

Todos los bytes llegaban; no todos los trabajos avanzaban

Imaginemos cuatro canales sobre el mismo TCP. Tres aplicaciones leen rápido. La cuarta se demora y su emisor tiene una respuesta voluminosa. TCP puede ordenar los bytes, recuperar una pérdida y conservar la conexión en buen estado. Aun así, las tres conversaciones pequeñas pueden quedar esperando detrás de la grande.

No falla la fiabilidad. Falla la asignación dentro de un recurso fiable.

Publicado en marzo de 2001 en Standards Track, RFC 3081 describió el mapeo de BEEP sobre TCP. Una sesión utilizaba una conexión y las tramas BEEP viajaban como octetos del flujo. El diseño era directo, pero no ingenuo: señalaba el hambre de recursos y el interbloqueo como riesgos cuando varios canales lógicos dependían del único contexto de flujo de TCP.

TCP administraba la conexión, no sus conversaciones

TCP no sabe qué octetos forman una orden de control, una consulta breve o una transferencia larga. Esas fronteras nacen en BEEP. Por eso el mapping incorporó una ventana deslizante independiente para cada canal.

Al abrirse, un canal disponía de 4096 octetos de carga útil. El receptor podía enviar después una trama SEQ con el siguiente número de secuencia esperado y la ventana que estaba dispuesto a recibir. El par de valores marcaba el borde local. Al alcanzarlo, el emisor debía detener sólo ese canal aunque la llamada de escritura TCP todavía aceptara datos.

No era una segunda capa de retransmisión. TCP ya entregaba orden y recuperación. El crédito BEEP respondía a otra pregunta: ¿cuánto material adicional puede introducir esta conversación en el soporte compartido?

Los números acababan dando la vuelta. RFC 3081 remitía a la aritmética serial de RFC 1982 y limitaba la ventana para que las comparaciones siguieran siendo inequívocas. Sin esa cautela, una posición antigua podría reaparecer como autorización nueva.

La señal de apertura debía adelantar a la carga

Una actualización no sirve si queda atrapada detrás del tráfico que pretende liberar. Cuando una trama SEQ espera en la misma cola ordinaria, la realimentación puede detenerse. El RFC le dio prioridad sobre las demás tramas.

La prioridad expresaba causalidad, no prestigio. Antes de admitir más carga, el receptor debía poder comunicar que existía espacio. El control necesitaba una vía de salida incluso cuando los datos habían llenado su presupuesto.

Para canales de la misma prioridad, el documento recomendó round-robin. No prometía idéntica latencia ni justicia matemática bajo cualquier búfer de sistema operativo. Fijaba una regla mínima: vaciar continuamente un canal activo no debía eliminar el turno de sus vecinos listos.

El consumidor final seguía más arriba

Que TCP haya recibido un octeto no significa que BEEP lo haya admitido para siempre; que BEEP lo haya admitido tampoco prueba que la aplicación lo haya procesado. Son tres recibos. RFC 1122 definía TCP como flujo fiable, no como transacción de aplicación, y RFC 9293 mantiene esa frontera.

Los usos posteriores muestran su importancia. RFC 3195 montó syslog fiable sobre perfiles BEEP. RFC 4744 hizo lo propio con NETCONF. El avance de secuencia no demostraba que un registro estuviera almacenado ni que una configuración hubiera producido efecto. Sólo la capa dueña de la operación podía afirmarlo.

Una ventana era permiso acotado

El receptor controlaba la capacidad anunciada porque soportaba el coste de memoria y entrega. El emisor elegía el siguiente canal elegible, sujeto al crédito y a la prioridad. TCP regulaba congestión y fiabilidad de la conexión. La aplicación decidía cuándo existía resultado.

RFC 3081 dejó una lección más amplia que BEEP. Numerar vías no las vuelve independientes. La independencia exige presupuestos propios, realimentación que no quede enterrada bajo la carga gobernada y turnos visibles que impidan a un usuario legítimo apropiarse silenciosamente de todo el soporte.

Fuentes

  1. https://www.rfc-editor.org/info/rfc3081
  2. https://www.rfc-editor.org/rfc/rfc3081.html
  3. https://datatracker.ietf.org/doc/rfc3081/
  4. https://www.rfc-editor.org/rfc/rfc3080.html
  5. https://www.rfc-editor.org/rfc/rfc1982.html
  6. https://www.rfc-editor.org/rfc/rfc1122.html
  7. https://www.rfc-editor.org/rfc/rfc9293.html
  8. https://www.rfc-editor.org/rfc/rfc3195.html
  9. https://www.rfc-editor.org/rfc/rfc4744.html
  10. https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
  11. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  12. https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/