Resumen

  • RFC 1080 permitía que un proceso Telnet pidiera a otro activar o desactivar el control de flujo por software, pero solo después de que DO y WILL establecieran esa autoridad limitada.
  • La opción gobernaba la salida entre el Telnet de usuario y su terminal adjunto. No detenía TCP ni la aplicación remota, y tampoco confirmaba que el controlador local hubiera obedecido.
  • El acuerdo comenzaba en un estado conocido, con el flujo activado; al retirar la opción cesaban las órdenes y podía reaparecer un valor predeterminado propio de la implementación.

Dos usos para los mismos caracteres

El teclado del terminal virtual definido por RFC 854 podía producir los 128 códigos US-ASCII. Una aplicación tenía derecho a esperar cualquiera de ellos. Algunos editores utilizaban Control-S o Control-Q como órdenes ordinarias.

El controlador del terminal podía ver otra cosa. En el control de flujo por software, XOFF —habitualmente Control-S— detenía la salida y XON —Control-Q— la reanudaba. El controlador consumía esos valores antes de que cruzaran la sesión.

Activar la interceptación protegía una pantalla o a una persona que no podía leer al ritmo de la salida. Mantenerla activa dentro de un editor podía borrar una instrucción válida. El sentido del byte no estaba escrito para siempre en el byte: dependía del mecanismo local y de quién estaba autorizado a cambiarlo.

RFC 1080, de noviembre de 1988, asignó el código 33 a TOGGLE-FLOW-CONTROL. No entregó el terminal al servidor. Creó un canal acotado para solicitar un estado.

Primero se acordaba la autoridad

RFC 855 describía dos fases para las opciones con parámetros. Las partes acordaban primero usar la opción; después podían subnegociar. En el caso normal, el host enviaba DO y el Telnet de usuario respondía WILL.

DO expresaba disposición a enviar órdenes de activación y desactivación. WILL aceptaba ejecutarlas. DONT y WONT negaban esos papeles. No eran una lectura del estado local: un cliente podía rechazar la opción y aun así mantener control de flujo por su cuenta.

Antes del intercambio completo no se permitían ON ni OFF. Tampoco después de revocar la opción. La secuencia impedía que una orden creara por sí sola la legitimidad para modificar el otro extremo.

El protocolo podía usarse en ambas direcciones, pero estaba pensado de manera asimétrica. El servidor sabía cuándo su programa necesitaba Control-S como dato; el cliente poseía la conexión física y lógica con el terminal.

El consentimiento daba un estado inicial conocido

Tras DO/WILL, quien había enviado DO podía pedir OFF o ON. El receptor cambiaba el control de flujo en el camino desde su proceso Telnet hacia la pantalla. No se tocaba la ventana TCP, la cola de un router ni el proceso que generaba la salida.

RFC 1080 exigía que el emisor de WILL activara el control de flujo inmediatamente después del acuerdo. Así, la sesión no arrancaba en una incógnita: el acuerdo mismo establecía el primer modo.

La certeza terminaba ahí. El documento no definía un acuse para cada ON u OFF. Una captura demostraba que se envió una solicitud válida, no que el controlador pudiera aplicarla, que la terminal estuviera pausada ni que un carácter llegara a la aplicación.

Los códigos de subnegociación desconocidos debían ignorarse. Era una protección de compatibilidad; también una advertencia contra interpretar el silencio como confirmación.

Al revocar, mandaba otra vez el valor local

Cualquiera de los extremos podía emitir DONT o WONT. Desde ese momento no podían circular más cambios de opción 33 hasta una nueva negociación.

El último modo no quedaba congelado. La especificación permitía volver a un estado predeterminado por la implementación. Por eso un inventario basado en «última orden vista» se vuelve falso después de una desconexión, una revocación o un reinicio.

La frontera era deliberada. El servidor recibía una capacidad temporal dentro de una sesión aceptada. Cuando ese contrato terminaba, el cliente recuperaba su política local. La interoperabilidad no exigía convertir una preferencia remota en propiedad permanente.

«Flujo» no significaba TCP

La opción se limitaba a los datos que el proceso Telnet de usuario enviaba a su terminal. El sentido inverso podía tener otra configuración. El control por hardware podía operar mediante señales dedicadas y no consumir ningún carácter.

Nada de eso era control de congestión. El TCP podía seguir aceptando datos; el servidor podía seguir calculando; los búferes podían conservar salida pendiente. Detener la pantalla no era detener Internet.

Una afirmación operativa debe indicar dirección y punto de observación. Control-S en el teclado, XOFF en un controlador, una petición OFF en la red y una pausa visible son cuatro pruebas relacionadas, pero distintas.

Linemode situó las demás decisiones locales

RFC 1184 permitió que el cliente Telnet hiciera edición de línea y tratamiento de señales cerca del usuario. En enlaces de gran retardo, enviar una línea completa podía resultar mucho más cómodo que depender de un viaje de red por pulsación.

El control de flujo parecía pertenecer al mismo conjunto, pero Linemode lo dejó en la opción separada. Eso evitó que un nuevo mapa de modos cambiara sin aviso un autómata ya definido.

También obliga a reconstruir toda la ruta del carácter: teclado, controlador, cliente Telnet y aplicación servidora. Cada componente puede consumir o transformar la entrada. La visibilidad de uno no equivale a la verdad de todos.

RFC 1372 añadió una petición que podía quedar sin confirmar

RFC 1372 sustituyó a RFC 1080 en 1992. Añadió RESTART-XON, para reanudar solo con XON, y RESTART-ANY, para permitir cualquier carácter salvo otro XOFF.

El control de flujo seguía activándose en un estado conocido al acordar la opción. La regla de reanudación, en cambio, empezaba como una decisión del sistema. El servidor debía solicitar la variante deseada.

Un cliente que no pudiera ofrecer ambas variantes podía ignorar la orden. No existía una respuesta para informar al servidor. La intención viajaba por el protocolo; la capacidad efectiva permanecía local y parcialmente invisible.

Además, en muchos controladores XON y XOFF se consumían. Con RESTART-ANY, un carácter ordinario podía reanudar la salida y continuar hasta la aplicación. Reanudar y entregar eran decisiones superpuestas, no una sola.

El puerto serie tenía superficies diferentes

RFC 2217 definió después ajustes para puertos serie y órdenes de suspensión de una sesión Telnet. FLOWCONTROL-SUSPEND detenía datos y comandos hasta RESUME; otros mensajes elegían mecanismos de flujo en el puerto.

No eran sinónimos de RFC 1080. Configurar el dispositivo, suspender toda la sesión e interceptar XON/XOFF en el cliente responden a autoridades y resultados distintos.

El registro de opciones Telnet de IANA conserva Remote Flow Control en el código 33 y cita RFC 1372. Prueba que el número sigue coordinado, no que una implementación actual lo use o lo cumpla.

Cinco capas para no confundir intención y efecto

Una investigación debe separar:

  1. consentimiento, mediante DO y WILL en una sesión concreta;
  2. modo solicitado, mediante ON, OFF o una regla de reinicio;
  3. estado local aplicado en cliente y controlador;
  4. tratamiento del carácter, consumido o reenviado;
  5. resultado observado, tanto en pantalla como en la aplicación.

RFC 1080 estandarizó las dos primeras capas y un punto de partida. No convirtió las restantes en consecuencias demostradas.

Su lección histórica cabe en una frase: el control remoto fue interoperable porque era revocable y estrecho. Control-S era una orden solo mientras el acuerdo y el mecanismo local mantenían ese significado.

Fuentes y límites

RFC 854 aporta el NVT; RFC 855, la gramática de negociación; RFC 1080, el diseño original; RFC 1184, el límite de Linemode; RFC 1372, los modos de reinicio; RFC 2217, el control serie y de sesión; IANA, el registro. Ninguna demuestra uso actual, identidad, autorización general, estado aplicado, incidente real ni resultado final.