Control de flujo de software

El control de flujo por software es un método de control de flujo utilizado en enlaces de datos informáticos , especialmente en la comunicación serial RS-232 . Utiliza códigos especiales, transmitidos dentro de la banda , a través del canal de comunicación principal. Estos códigos se denominan generalmente XOFF y XON (de "transmit off" y "transmit on", respectivamente). Por lo tanto, el "control de flujo por software" a veces se denomina "control de flujo XON/XOFF". Esto contrasta con el control de flujo mediante señales dedicadas fuera de banda —" control de flujo por hardware "— como RS-232 RTS/CTS .

En los sistemas que utilizan el código de caracteres ASCII , XOFF generalmente se representa mediante un carácter o byte con valor decimal 19; XON con valor 17.

El estándar ASCII no reserva ningún carácter de control para su uso específico como XON/XOFF. Sin embargo, sí proporciona cuatro caracteres genéricos de "control de dispositivo" (DC1 a DC4). El Teletype Modelo 33 ASR adoptó dos de ellos, DC3 y DC1, para su uso como XOFF y XON, respectivamente. Este uso fue copiado por otros y ahora es un estándar de facto . Los equivalentes en teclado de Ctrl+S para XOFF y + para XON también derivan de este uso.CtrlQ

Cuando un extremo de un enlace de datos ya no puede aceptar más datos (o está a punto de hacerlo), envía la señal XOFF al otro extremo. Este último recibe el código XOFF y suspende la transmisión . Una vez que el primer extremo está listo para aceptar datos nuevamente, envía la señal XON y el otro extremo reanuda la transmisión.

Por ejemplo, podemos imaginar una computadora enviando datos a una impresora lenta . Dado que la computadora envía los datos más rápido de lo que la impresora puede imprimirlos, esta última se retrasa y se encuentra en una situación en la que se verá saturada de datos. La impresora reacciona enviando XOFF a la computadora, que detiene temporalmente el envío de datos. Cuando la impresora está lista para recibir más datos, envía XON a la computadora, que reanuda el envío de datos.

La función XOFF/XON puede utilizarse en ambas direcciones, por ejemplo, entre dos teletipos conectados entre sí.

La principal ventaja del control de flujo por software es la reducción del número de conductores eléctricos entre el emisor y el receptor. Con una conexión a tierra común , solo se necesitan dos señales: una para enviar y otra para recibir. El control de flujo por hardware requiere cables adicionales entre los dos dispositivos. Además, requiere una implementación de hardware específica, lo que implicaba costes más elevados en los inicios de la informática (es decir, en las décadas de 1960 y 1970).

Sin embargo, el control de flujo por software no está exento de problemas. El inconveniente más importante es su menor fiabilidad. El envío de XOFF requiere al menos un tiempo de transmisión de carácter y puede quedar en cola detrás de datos ya transmitidos que aún se encuentran en los búferes. Las señales de hardware pueden activarse casi instantáneamente y fuera de orden.

Como su nombre lo indica, el control de flujo mediante software se implementa generalmente en software (o firmware ), lo que puede causar retrasos adicionales en la respuesta XOFF. Estos retrasos pueden provocar corrupción de datos debido a desbordamientos de búfer . El control de flujo por hardware, por otro lado, suele estar bajo el control directo de la UART transmisora , que puede detener la transmisión inmediatamente, sin la intervención de niveles superiores. Para gestionar la latencia causada por las FIFO integradas , las UART más avanzadas, como la 16950, proporcionan control de flujo por software integrado. ^{[ 1 ]} Las UART que carecen de este soporte, como la 16550 , pueden sufrir desbordamientos de búfer al usar el control de flujo por software, aunque esto se puede mitigar en cierta medida deshabilitando la FIFO de la UART. ^{[ 1 ]}

Finalmente, dado que los códigos XOFF/XON se envían dentro de la banda, no pueden aparecer en los datos transmitidos sin confundirse con comandos de control de flujo. Por lo tanto, cualquier dato que contenga los códigos XOFF/XON debe codificarse de alguna manera para su correcta transmisión, con la consiguiente sobrecarga. Esto se suele hacer mediante una secuencia de escape . Para los dispositivos de impresión que interpretan directamente códigos ASCII, esto no supone un gran problema, ya que los códigos XON y XOFF utilizan números de código ASCII de "control de dispositivo".

El control de flujo por software es ampliamente utilizado por dispositivos de baja velocidad, especialmente impresoras antiguas y terminales tontas , para indicar que temporalmente no pueden aceptar más datos. Por lo general, esto se debe a una combinación de una velocidad de salida limitada y a que los búferes están llenos. Algunos paquetes de control de terminales, como termcap , emplean "retrasos" (pequeños retardos con granularidad de milisegundos ^{[ 2 ]} ) para permitir que dichos equipos tengan tiempo suficiente para realizar las acciones solicitadas sin necesidad de activar XOFF.

Los operadores de ordenadores todavía utilizan a veces manualmente las funciones XOFF/XON para pausar y reanudar la salida de datos que, de otro modo, desaparecería de la pantalla demasiado rápido.

El software emulador de terminal generalmente implementa la compatibilidad con XOFF/XON como una función básica. Esto generalmente incluye la consola del sistema en máquinas Unix y Linux modernas , así como emuladores de GUI como xterm y la consola Win32 .

El protocolo Robust XON es una técnica para reiniciar la comunicación, en caso de que se haya interrumpido por la recepción accidental de un XOFF. La unidad receptora envía caracteres XON periódicamente cuando puede recibir datos y la línea está inactiva. Un uso común es en impresoras seriales (como la HP LaserJet II) para indicar que están en línea y listas para recibir datos. El XON se envía cada 1 a 30 segundos, según el firmware de la impresora.

• Control de flujo Ethernet

• Impresoras HP LaserJet IIP e IIP Plus: Teclas y menús del panel de control . Hewlett-Packard . Archivado del original el 9 de mayo de 2006.