El control de flujo por software es un método de control de flujo utilizado en enlaces de datos de computadoras , especialmente en la serie RS-232 . Utiliza códigos especiales, transmitidos en banda , a través del canal de comunicaciones principal. Estos códigos generalmente se denominan XOFF y XON (de "transmisión desactivada" y "transmisión activada", 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 a través de señales fuera de banda dedicadas (" control de flujo por hardware "), como RS-232 RTS/CTS .
Para 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 Model 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 del teclado de Ctrl+ Spara XOFF y + para XON también derivan de este uso.CtrlQ
Cuando un extremo de un enlace de datos no puede aceptar más datos (o se acerca a ese punto), envía XOFF al otro extremo. El otro extremo recibe el código XOFF y suspende la transmisión . Una vez que el primer extremo está listo para aceptar datos nuevamente, envía XON y el otro extremo reanuda la transmisión.
Por ejemplo, podemos imaginarnos una computadora que envía datos a una impresora lenta . Como la computadora envía datos más rápido que la impresora, la impresora se queda atrás y se acerca a una situación en la que se vería abrumada por los datos. La impresora reacciona a esta situación enviando XOFF a la computadora, que deja de enviar datos temporalmente. Cuando la impresora está nuevamente lista para recibir más datos, envía XON a la computadora, que comienza a enviar datos nuevamente.
XOFF/XON se puede utilizar en ambas direcciones, por ejemplo, dos teleimpresoras conectadas entre sí.
La principal ventaja del control de flujo por software es la reducción del número de conductores eléctricos entre el transmisor y el receptor. Dada 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. También requiere una implementación de hardware específica, que tenía costos más significativos en los primeros tiempos de la informática (es decir, en los años 1960 y 1970).
Sin embargo, el control de flujo de software no está exento de problemas. El inconveniente más importante es que el control de flujo de software es menos confiable. El envío de XOFF requiere al menos un tiempo de carácter para transmitirse 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 lo indica el nombre "control de flujo de software", el control de flujo que utiliza este método generalmente se implementa en software (o firmware ), lo que puede causar más demoras en la respuesta XOFF. Estas demoras pueden provocar corrupción de datos debido a desbordamientos de búfer . El control de flujo de hardware, por otro lado, generalmente está bajo el control directo del UART transmisor , que puede detener la transmisión inmediatamente, sin la intervención de niveles superiores. Para manejar la latencia causada por los FIFO integrados , los UART más avanzados, como el 16950, brindan control de flujo de software "en chip". [1] Los UART que carecen de dicho soporte, como el 16550 , pueden sufrir desbordamientos de búfer cuando usan control de flujo de software, aunque esto se puede mitigar de alguna manera deshabilitando el FIFO del UART. [1]
Por último, dado que los códigos XOFF/XON se envían en banda, no pueden aparecer en los datos que se transmiten sin confundirse con comandos de control de flujo. Por lo tanto, todos los datos que contienen los códigos XOFF/XON deben codificarse de alguna manera para una transmisión adecuada, con la sobrecarga correspondiente. Esto se hace con frecuencia con algún tipo de secuencia de escape . Para los dispositivos de impresión que interpretan directamente los códigos ASCII, esto no es un gran problema, porque los códigos XON y XOFF utilizan números de código de "control de dispositivo" ASCII .
El control de flujo de 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. Normalmente, esto se debe a una combinación de velocidad de salida limitada y búferes llenos. Algunos paquetes de control de terminales, como termcap , emplean "relleno" (breves retrasos que utilizan granularidad de milisegundos [2] ) para permitir que dichos equipos tengan tiempo suficiente para realizar las acciones solicitadas sin la necesidad de activar XOFF.
Los operadores de computadoras todavía utilizan a veces manualmente XOFF/XON para pausar y reiniciar la salida que, de lo contrario, se desplazaría demasiado rápido fuera de la pantalla.
El software emulador de terminal generalmente implementa compatibilidad con XOFF/XON como 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 .
Robust XON es una técnica para reiniciar la comunicación, en caso de que se haya detenido por un XOFF recibido accidentalmente. La unidad receptora envía caracteres XON periódicos cuando puede recibir datos y la línea está inactiva. Un uso común es en impresoras seriales (como 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 diseño del firmware de la impresora.