Hubbry Logo
Software flow controlSoftware flow controlMain
Open search
Software flow control
Community hub
Software flow control
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Software flow control
Software flow control
Software flow control
View on Wikipedia
from Wikipedia

Software flow control is a method of flow control used in computer data links, especially RS-232 serial. It uses special codes, transmitted in-band, over the primary communications channel. These codes are generally called XOFF and XON (from "transmit off" and "transmit on", respectively). Thus, "software flow control" is sometimes called "XON/XOFF flow control". This is in contrast to flow control via dedicated out-of-band signals — "hardware flow control" — such as RS-232 RTS/CTS.

Representation

[edit]

For systems using the ASCII character code, XOFF is generally represented using a character or byte with decimal value 19; XON with value 17.

The ASCII standard does not reserve any control characters for use as XON/XOFF specifically. However, it does provide four generic "device control" characters (DC1 through DC4). The Teletype Model 33 ASR adopted two of these, DC3 and DC1, for use as XOFF and XON, respectively. This usage was copied by others, and is now a de facto standard. The keyboard equivalents of Ctrl+S for XOFF, and Ctrl+Q for XON, also derive from this usage.

XOFF/XON representations in ASCII
Code Meaning ASCII Dec Hex Keyboard
XOFF Pause transmission DC3 19 13 Ctrl+S
XON Resume transmission DC1 17 11 Ctrl+Q

Mechanism

[edit]

When one end of a data link is unable to accept any more data (or approaching that point), it sends XOFF to the other end. The other end receives the XOFF code, and suspends transmission. Once the first end is ready to accept data again, it sends XON, and the other end resumes transmission.

For example, one may imagine a computer sending data to a slow printer. Since the computer is faster at sending data than the printer can print it, the printer falls behind and approaches a situation where it would be overwhelmed by the data. The printer reacts to this situation by sending XOFF to the computer, which temporarily stops sending data. When the printer is again ready to receive more data, it sends XON to the computer, which starts sending data again.

XOFF/XON can be employed in both directions, for example, two teleprinters connected to each other.

Comparison with hardware flow control

[edit]

The principal advantage of software flow control is the reduction in the number of electrical conductors between sender and receiver. Given a common ground, only two signals are needed, one to send and the other to receive. Hardware flow control requires additional wires between the two devices. It also requires specific hardware implementation, which had more significant costs in earlier days of computing (i.e., 1960s and 70s).

However, software flow control is not without its problems. The most important drawback is that software flow control is less reliable. Sending XOFF requires at least one character time to transmit, and may be queued behind already-transmitted data still in buffers. Hardware signals may be asserted almost instantaneously, and out-of-order.

Summary of flow control tradeoffs
Type Data integrity Low cost Out of Band
Hardware flow control Most reliable No Yes
On-chip software f.c. Good Some No
Software f.c. (FIFO disabled) Good, but slow Yes No
Software f.c. (FIFO enabled) Unreliable Yes No

As the name "software flow control" implies, flow control using this method is usually implemented in software (or firmware), which can cause further delays in XOFF response. These delays can lead to data corruption due to buffer overruns. Hardware flow control, on the other hand, is typically under the direct control of the transmitting UART, which is able to cease transmission immediately, without the intervention of higher levels. To handle the latency caused by builtin FIFOs, more advanced UARTs, like the 16950, provide "on-chip" software flow control.[1] UARTs that lack such support, like the 16550, may suffer from buffer overruns when using software flow control, although this can be somewhat mitigated by disabling the UART's FIFO.[1]

Finally, since the XOFF/XON codes are sent in-band, they cannot appear in the data being transmitted without being mistaken for flow control commands. Any data containing the XOFF/XON codes thus must be encoded in some manner for proper transmission, with corresponding overhead. This is frequently done with some kind of escape sequence. For printing devices that directly interpret ASCII codes, this is not a large problem, because the XON and XOFF codes use ASCII "device control" code numbers.

Applications

[edit]

Software flow control is used extensively by low-speed devices, especially older printers and dumb terminals, to indicate they are temporarily unable to accept more data. Typically, this is due to a combination of limited output rate and any buffers being full. Some terminal control packages, such as termcap, employ "padding" (short delays using millisecond granularity[2]) to allow such equipment sufficient time to perform the requested actions without the need to assert XOFF.

XOFF/XON are still sometimes used manually by computer operators, to pause and restart output which otherwise would scroll off the display too quickly.

Terminal emulator software generally implements XOFF/XON support as a basic function. This generally includes the system console on modern Unix and Linux machines, as well as GUI emulators such as xterm and the Win32 console.

Robust XON is a technique to restart communication, just in case it was stopped by an accidentally received XOFF. The receiving unit sends periodic XON characters when it can receive data, and the line is idle. One common use is by serial printers (like HP LaserJet II) to indicate they are online and ready to receive data. The XON is sent every 1 to 30 seconds depending on the printer's firmware design.

See also

[edit]

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Software flow control

View on Grokipedia
from Grokipedia
Software flow control, also known as XON/XOFF flow control, is a method used in data communications to regulate the transmission rate between a sender and receiver by embedding special control characters within the itself, allowing the receiver to signal when to pause or resume data flow without requiring additional hardware signals. This technique operates in-band, meaning the control signals are transmitted over the same channel as the primary data, typically in asynchronous serial links such as RS-232. The receiver initiates flow control by sending an XOFF character (ASCII code 19, equivalent to Control-S or DC3) to the sender when its input buffer approaches capacity, prompting the sender to halt transmission temporarily. Once the receiver has processed enough data to free up buffer space, it sends an XON character (ASCII code 17, equivalent to Control-Q or DC1) to instruct the sender to resume. This mechanism ensures that the receiver is not overwhelmed, preventing due to . In contrast to hardware flow control, which relies on dedicated control lines like Request to Send (RTS) and Clear to Send (CTS) for signaling, software flow control is simpler and more cost-effective as it does not necessitate extra wiring or circuitry. However, it carries limitations, including vulnerability to interference in streams where XON or XOFF characters may appear naturally, potentially causing unintended pauses, and it introduces slight latency due to the processing of these inline characters. Software flow control finds primary application in legacy environments, terminal emulation software, and certain network protocols, such as the Telnet remote flow control option, where it enables efficient data handling in resource-constrained or software-driven systems. Its adoption dates back to early computing eras, integrated into standards for teletype and terminal operations to manage punch tape and printer outputs.

Fundamentals

Definition and Purpose

Software flow control, also known as XON/XOFF flow control, is an technique used in serial communications to regulate data transmission rates between a sender and receiver. It operates by embedding specific control characters directly within the data stream over point-to-point links, such as (also referred to as EIA-232), to instruct the transmitter to pause (via XOFF) or resume (via XON) sending data. This method is inherently software-based, relying on the devices' protocols to detect and act upon these characters without additional hardware intervention. The core purpose of software flow control is to prevent in the receiving device by enabling it to dynamically a faster transmitter, thereby preserving in asynchronous serial environments where processing speeds or buffer sizes may mismatch. In scenarios involving character-oriented data transmissions, such as text-based protocols, it ensures reliable delivery by pausing transmission when the receiver's buffer approaches capacity and resuming once space is available, avoiding that could occur from unchecked high-speed input. This approach is particularly valuable in legacy or resource-constrained systems lacking dedicated control lines. As a subset of broader flow control strategies, software flow control is distinguished by its character-oriented nature, where it interprets and responds to embedded signals in the primary data channel, making it suitable for asynchronous serial links but incompatible with streams that might interpret control characters as . Unlike hardware-based alternatives, it achieves flow regulation solely through software processing over the existing transmit and receive lines, promoting simplicity in cabling while depending on mutual protocol agreement between communicating devices.

Historical Development

Software flow control emerged in the alongside the development of early computer terminals and teletypewriters, driven by the need to manage data transmission in resource-limited environments. The ASR-33, introduced in 1963 by , played a pivotal role in its origins by utilizing ASCII control characters DC1 (Device Control 1, also known as XON or Ctrl-Q) and DC3 (Device Control 3, also known as XOFF or Ctrl-S) to control auxiliary devices such as the automatic tape reader. In this context, DC1 initiated tape reading operations, while DC3 halted them, preventing mechanical overload and data garbling during paper tape and terminal interactions. This mechanism evolved into a de facto standard for software-based transmission regulation in early computer systems, particularly as serial interfaces proliferated before the full adoption of hardware flow control protocols. The ASCII standard (ANSI X3.4-1963), published that same year, formalized DC1 and DC3 as generic device control characters without prescribing specific flow control semantics, but their practical application in teletype operations filled this gap for simple, in-band signaling in hardware-constrained setups. By the 1970s, with the widespread implementation of RS-232 serial standards (initially defined in 1960 and revised in 1969), software flow control persisted as a lightweight alternative, especially in minicomputers and terminals where additional wiring for hardware signals was impractical. Although lacking a dedicated formal standard from bodies like ITU or IEEE, software flow control became ubiquitous in operating systems and communications by the 1980s, integrated into terminal drivers for pausing and resuming output to manage buffer overflows. Key events included the shift from mechanical teletypes like the Model 33 to electronic terminals in the late and , which retained XON/XOFF compatibility for . Its prominence waned after the with the rise of dedicated hardware flow control in high-speed networks, yet it endures in software emulations and legacy serial applications.

Technical Details

Representation in Data Streams

Software flow control employs specific control characters embedded within the data stream to manage transmission pacing. The primary characters are XON, which signals the resumption of data transmission, and XOFF, which instructs a pause in transmission. XON corresponds to ASCII control code DC1 (decimal 17, hexadecimal 0x11, equivalent to Ctrl+Q), while XOFF is ASCII DC3 (decimal 19, hexadecimal 0x13, equivalent to Ctrl+S). These characters are transmitted in-band, meaning they are sent directly as part of the serial data stream over the standard transmit (TX) and receive (RX) lines, without requiring dedicated hardware signals or additional wiring beyond the basic RS-232 interface. This approach integrates flow control seamlessly into the primary communication channel, leveraging the existing ASCII framework for compatibility with character-oriented protocols. The encoding of XON and XOFF typically adheres to 7-bit ASCII standards, though 8-bit extensions are common in modern implementations to support extended character sets. In scenarios involving transmission, where arbitrary byte values may coincide with XON or XOFF codes, these control characters must be escaped to prevent unintended flow control triggers. Common escaping techniques include prefixing the offending byte with a designated (such as DLE, hexadecimal 0x10) or doubling the byte itself, allowing the receiver to distinguish data from control signals. While XON/XOFF represents the for software flow control due to its widespread adoption and compatibility, some systems employ variants such as ETX (End of Text, ASCII code 3) paired with ACK for acknowledgment-based pausing, or entirely custom control codes tailored to specific protocols. These alternatives are less common and typically limited to legacy or specialized environments where standard ASCII controls are insufficient.

Operational Mechanism

In software flow control, the receiver continuously monitors the occupancy of its incoming to prevent overflow. When the buffer reaches a high threshold—typically around 80% of its capacity—the receiver generates and transmits an back to over the , instructing it to pause transmission. The receiver continues to accept and incoming during this period, gradually reducing the buffer level until it falls below a low threshold, at which point the receiver sends an to signal readiness for resumed transmission. Upon interpreting the XOFF character, the sender immediately halts further data transmission after completing the current byte in progress, transitioning into a "stopped" state where it locally buffers any pending outgoing data to avoid loss. The sender remains in this state until it receives an XON character, at which point it resumes transmission and returns to the "transmitting" state. To manage potential signal loss, some implementations incorporate timeouts, ensuring the protocol does not deadlock indefinitely. A typical operational sequence occurs in a terminal-to-printer configuration, where the printer, upon nearing buffer capacity while receiving print data from the host terminal, transmits an XOFF character to the host. The host then pauses its output stream, allowing the printer to and clear its buffer; once sufficient is available, the printer sends an XON, prompting the host to continue sending data. For enhanced reliability in edge cases, robust implementations may have the receiver periodically transmit XON characters while in a ready state to counteract potential loss of prior signals. The protocol operates without formal acknowledgments for these control characters, relying on an assumption of an error-free channel to maintain synchronization between sender and receiver.

Comparative Analysis

With Hardware Flow Control

Hardware flow control in serial communications, particularly under the (EIA-232) standard, relies on dedicated signals transmitted via additional pins to regulate flow between devices. The primary mechanism involves the Request to Send (RTS) signal, asserted by the (DTE) to indicate transmission readiness, and the Clear to Send (CTS) signal, asserted by the (DCE) to confirm reception capability. Alternative signals like (DTR) and Data Set Ready (DSR) may also be used in some configurations. These signals operate independently of the channel, using voltage levels of +3V to +15V for assertion and -3V to -15V for negation. Software flow control differs fundamentally from this hardware approach by operating in-band over the data lines, requiring only two wires (transmit and receive) at minimum, whereas hardware methods demand at least four wires for the control signals. This in-band nature makes software flow control more cost-effective and simpler to implement without extra hardware, but it exposes the to interference where data bytes might mimic control characters like XOFF, potentially disrupting flow erroneously. Hardware flow control avoids such issues through its segregated signaling, providing greater isolation from data content. A primary advantage of software flow control in comparison to hardware is its compatibility with minimal cabling setups, enabling reliable operation over modems or lines without necessitating hardware modifications or additional pins. This makes it ideal for resource-constrained or legacy environments where simplicity trumps performance. However, software flow control exhibits notable drawbacks relative to hardware methods, including a potential latency of up to 15 characters for control and transmission, elevated CPU overhead for continuous , and susceptibility to transmission errors such as triggering false halts via misinterpreted XOFF characters. In contrast, hardware flow control delivers instantaneous response through direct signal assertion, minimizing delays and enhancing reliability, especially for where control characters could occur naturally. It also reduces the risk of buffer overruns in high-throughput scenarios. Use case distinctions further highlight these trade-offs: software flow control suits low-speed legacy systems with baud rates below 9600, where cabling simplicity outweighs minor delays, while hardware flow control is preferred for modern UART-based applications supporting speeds up to 115200 or higher, prioritizing low latency and robustness in performance-critical setups.

With Higher-Layer Flow Control

Higher-layer flow control, as implemented in transport protocols like TCP, operates at the end-to-end level across IP networks to regulate data transmission rates based on receiver capabilities. In TCP, this is achieved through a sliding window mechanism where the receiver advertises its available buffer space (the window size) in acknowledgment (ACK) packets, allowing the sender to adjust its transmission rate dynamically and prevent . This approach ensures reliable delivery over multi-hop paths by integrating flow control with error detection and retransmission, contrasting with the more localized scope of software flow control. Key differences between software flow control and higher-layer methods like TCP lie in their architectural layers and operational scopes. Software flow control functions at the , providing point-to-point, character-oriented regulation typically via in-band signals like XON/XOFF for serial connections, without support for or multi-hop traversal. In contrast, TCP operates at the , employing packet-based sliding windows for end-to-end control across potentially congested networks, and incorporates congestion avoidance algorithms such as Reno, which uses additive increase and multiplicative decrease based on feedback, or Cubic, which employs a for more aggressive window growth in high-bandwidth-delay product environments. These higher-layer mechanisms address network-wide variability, including round-trip time (RTT) estimations, whereas software flow control remains confined to direct links without inherent or path adaptation. Software flow control offers advantages in immediacy and simplicity for serial links, enabling rapid, low-overhead pausing and resumption of data streams without dedicated hardware signals, making it suitable for resource-constrained, point-to-point setups. However, TCP's higher-layer approach provides greater for modern networks through its ability to handle variable delays and integrate congestion control, though this introduces complexity from RTT calculations and . On the downside, software flow control is limited to near-unidirectional control and lacks built-in error recovery, potentially leading to if control characters are misinterpreted in binary streams, while TCP combines flow control with reliability features like selective retransmissions and adapts to diverse network conditions. In terms of , software flow control is often layered beneath higher-layer protocols in scenarios like serial-over-IP tunneling, where RFC 2217 extends to negotiate and manage serial port parameters, including XON/XOFF signaling, over TCP connections for remote access. Despite this compatibility in legacy integrations, TCP has largely superseded software flow control for contemporary networked applications due to its robust end-to-end guarantees and support for internet-scale communication.

Applications

In Legacy Systems

Software flow control, particularly through the XON/XOFF protocol, played a crucial role in managing data transmission in legacy systems reliant on serial communications, such as RS-232 interfaces, where hardware limitations necessitated in-band signaling to prevent buffer overflows. In RS-232 terminals like the VT100, XON/XOFF ensured orderly processing of characters and commands by requiring minimal software support on the host side, allowing the terminal to pause and resume output as needed during interactive sessions. Similarly, dot-matrix printers connected via RS-232 used software flow control to pause text output when internal buffers filled, maintaining reliable printing on slower mechanical devices without dedicated hardware handshaking lines. Acoustic modems adhering to the Hayes command set, common in dial-up connections during the 1980s and 1990s, incorporated XON/XOFF through commands like AT&K4 to enable software flow control, facilitating stable data exchange over variable telephone lines. In protocols like , introduced in 1979 for Unix-to-Unix file transfers, software flow control via XON/XOFF was integrated to handle serial line constraints, with default characters set to manage flow in packet-based error-correcting modes. Early Systems (BBS), which relied on dial-up modems for remote access, similarly employed XON/XOFF to regulate character streams during file downloads and message navigation, ensuring compatibility with asynchronous serial connections. Manual pausing in text editors and console applications, such as using Ctrl+S (XOFF) to stop scrolling output, became a standard feature in legacy environments, originating from teletypewriter conventions to halt terminal display when users needed to review content. Specific devices exemplified these applications: Teletype terminals, including the Model 33 ASR, adopted XOFF (DC3) and XON (DC1) codes for software flow control to synchronize slow mechanical printing with faster host transmissions. Early personal computers, such as the IBM PC with its serial ports under , supported XON/XOFF in serial communications software like Kermit for interactions and peripheral control, allowing direct hardware access without advanced buffering. Minicomputers like the PDP-11 utilized XON/XOFF for console I/O, where the RT-11 operating system enabled recognition of Ctrl/Q (XON) and Ctrl/S (XOFF) characters to manage terminal interactions on serial lines. This reliance on software flow control persists in modern terminal emulators and simulators, such as and SIMH's PDP-11 emulator, which default to XON/XOFF support for compatibility with 1970s-1990s hardware behaviors, enabling accurate reproduction of legacy serial protocols in contemporary environments.

In Modern Contexts

In contemporary software environments, terminal emulators continue to leverage software flow control to manage s over serial connections, including those tunneled via SSH or emulated as virtual COM ports. , a widely used SSH and serial client, supports XON/XOFF by configuring the flow control option to send and receive these characters within the , preventing buffer overflows during serial interactions. Similarly, Tera Term enables XON/XOFF in its serial port setup menu, allowing users to select it alongside baud rate and parity settings for reliable communication with devices. On systems, tools like minicom and facilitate software flow control; minicom activates it through the configuration menu (Ctrl-A followed by O, then selecting software flow control), while screen relies on underlying stty commands to enable XON/XOFF for serial sessions, supporting SSH-tunneled serial access without hardware dependencies. These implementations ensure compatibility with virtual COM ports provided by USB-to-serial drivers, maintaining in software-defined serial environments. In embedded systems and IoT applications, software flow control remains essential for handling low-bandwidth sensor data streams on resource-constrained devices. The microcontroller's UART peripheral, as implemented in the ESP-IDF framework, provides built-in support for XON/XOFF through configurable functions that detect and transmit these characters to pause or resume transmission, preventing buffer overruns in sensor networks. USB-to-serial adapters using chips, common in IoT prototyping, incorporate XON/XOFF in their drivers to manage flow without additional hardware lines, enabling seamless integration with microcontrollers for data from low-speed sensors like temperature or humidity monitors. For Arduino-based projects, while the core Serial library lacks native XON/XOFF, developers implement it via custom code to monitor buffers and insert control characters, supporting reliable in bandwidth-limited IoT setups. Beyond core tools, software flow control appears in specialized debugging and communication scenarios. In GDB remote debugging over serial links, flow control settings, including XON/XOFF, are configured via the host's serial parameters to ensure stable packet transmission between the debugger and target device. Software-defined radios (SDRs) utilize it for control streams over serial interfaces, where XON/XOFF helps regulate command flows to radio hardware without overwhelming buffers during spectrum analysis or tuning operations. Recent trends indicate a resurgence of software flow control in hobbyist and retro computing projects, driven by the emulation of vintage hardware via modern USB-serial interfaces. Enthusiasts interfacing with 1980s-era terminals or consoles often enable XON/XOFF to replicate original behaviors, addressing modern driver limitations that previously hindered compatibility. Silicon Labs UART drivers in 2020s firmware offer partial XON/XOFF support, requiring application-level handling of buffer monitoring and character insertion, which facilitates its use in embedded hobbyist designs like custom retro emulators. This revival underscores software flow control's adaptability in niche, low-overhead applications where hardware alternatives are impractical.

References

  1. https://www.rfc-editor.org/rfc/rfc1372.html
  2. https://users.ece.cmu.edu/~koopman/ece348/lectures/11_serial_handouts.pdf
  3. https://www.silabs.com/documents/public/application-notes/an0059.0-uart-flow-control.pdf
  4. https://www.ni.com/docs/en-US/bundle/ni-serial/page/hardware-implemented-flow-control.html
  5. https://genesis.eecg.toronto.edu/seatsale/programs/www.beyondlogic.org/serial/serial.htm
  6. https://www.electronics-notes.com/articles/connectivity/serial-data-communications/rs232-software-handshaking-xon-xoff-ext-ack.php
  7. https://ftp1.digi.com/support/cabling/eia_232_info.pdf
  8. https://www.ti.com/lit/pdf/slla544
  9. https://www.brainboxes.com/faq/what-is-xon-xoff-software-flow-control
  10. https://www.computerhistory.org/revolution/minicomputers/11/337/1934
  11. http://bitsavers.org/communications/teletype/33/310B_Vol_1_33_Teletypewriter_Sets_Technical_Manual_Sep74.pdf
  12. https://landley.net/history/mirror/ascii.html
  13. https://man7.org/linux/man-pages/man3/termios.3.html
  14. https://www.brainboxes.com/faq/how-do-i-send-xon-xoff-character-to-control-data-flow
  15. https://www.windmill.co.uk/handshaking.html
  16. https://www.pccompci.com/Flow_Control.html
  17. https://www.lammertbies.nl/comm/info/rs-232-flow-control
  18. https://www.usconverters.com/understanding-rs232-comprehensive-guide-to-cables-and-connectors
  19. https://stackoverflow.com/questions/19519530/how-to-send-xon-xoff-in-case-of-binary-data
  20. https://www.ftdichip.com/Documents/AppNotes/AN232B-09_Modem_Emulation_Mode.pdf
  21. https://tldp.org/HOWTO/Text-Terminal-HOWTO-11.html
  22. https://dipsingh.github.io/FlowControl-HighSpeed-Networks/
  23. https://www.analog.com/en/resources/technical-articles/fundamentals-of-rs232-serial-communications.html
  24. https://www.camiresearch.com/Data_Com_Basics/RS232_standard.html
  25. https://datatracker.ietf.org/doc/html/rfc793
  26. https://www.baeldung.com/cs/tcp-flow-control-vs-congestion-control
  27. https://www.geeksforgeeks.org/computer-networks/flow-control-in-data-link-layer/
  28. https://www.geeksforgeeks.org/computer-networks/tcp-congestion-control-algorithms-reno-new-reno-bic-cubic/
  29. https://www.rfc-editor.org/rfc/rfc9438.html
  30. https://stackoverflow.com/questions/56568733/what-does-xon-xoff-flow-control-actually-do
  31. https://www.rfc-editor.org/rfc/rfc2217.html
  32. https://documentation.help/PuTTY/config-serial-flow.html
  33. https://learn.sparkfun.com/tutorials/terminal-basics/tera-term-windows
  34. https://wiki.emacinc.com/wiki/Getting_Started_With_Minicom
  35. https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/peripherals/uart.html
  36. https://www.ftdichip.com/Support/Knowledgebase/an232b_04flowctl.htm
  37. https://forum.arduino.cc/t/xon-xoff-in-arduino/1122946
  38. https://sourceware.org/gdb/current/onlinedocs/gdb.html/Remote-Configuration.html
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.