[Robelle] [SmugBook] [Index] [Prev] [Next]

Networks from RS-232 to TCP/IP

The first network was probably two cans connected with a piece of string or perhaps it was the system of signal-fire towers built by the Romans. Then came the RS-232 cable and a maze of A-B switches, terminal controllers, and patch panels.

RS-232 Cables

A simple and venerable form of network can be created using asynchronous serial connections, usually based on RS-232 cabling. Every PC comes with at least one RS-232 port on the back for plugging in a serial cable.

The RS-232C standard defines numerous pins, but only three are needed to directly connect a serial device to an MPE system: pins 2 (transmit data), 3 (receive data), and 7 (signal ground). The most common cabling problem is a mismatch of pins 2 and 3. Some devices expect these pins to be wired straight through; others expect them to be crossed over. If you get no response on your device, insert a Modem Eliminator Cable (also called a Null Modem Cable). This cable crosses over pins 2 and 3, 4 and 8, plus 6 and 20, with pin 7 wired straight through to pin 7. Warning: To connect a modem using a cable with only 3 pins, configure the modem to ignore DTR (that is, pretend it is present and high), don't enable hardware handshaking in your software (since you don't have RTS and CTS), and don't try to connect it to an HP 3000 modem port (since you are missing DCD and DSR).


"Parity" is a method of computing a simple checksum for a character sent over a communication link. Characters can have 7 data bits, plus a parity bit. The parity is computed by checking the total number of 1 bits in the character, then setting the eighth bit so that the count is always odd or always even. A terminal can compute parity in five ways:

Text version.

Odd parity=(make sum of the bits odd)
Even parity=(make sum of the bits even)
Mark parity=(parity bit is always 1, select "1's" on some terminals)
Space parity=(parity bit is always 0; "O's" on some terminals, "0" on 262x, "None" on 264x)
None/8=8 bits used for data, no parity computed

MPE/iX defaults to None/8, no parity, with 1 start bit and 1 stop bit, which allows you to transmit 8-bit extended characters, instead of just the 128-character ASCII character set. MPE V senses your parity when you press Return during logon; MPE V supports None/8, but defaults to 1 start bit, 1 parity bit, 1 stop bit (2 stop bits slows throughput by 10 percent), and 7 data bits (UART chips are actually capable of 5, 6, 7 or 8 data bits, in addition to parity, not just 7). UNIX expects 7 data bits with Parity, but HP-UX can be configured to accept None/8. Because many UNIX systems are configured for 7 bits, you may find it difficult or impossible to transfer extended characters over a TELNET or serial connection. Reflection, for example, has a 7 bit Transfer Link option which we use whenever transferring files to, from, or through any type of UNIX system.

ASCII Versus Binary File Transfers

Transfers of non-text files should always be done in Binary mode (the actual command is Type Image in the FTP standard). The problem has to do with interpretation of received data, not just parity. ASCII transfers, for instance, usually attach great significance to embedded CRs and LFs. For instance, if you send an executable application using XMODEM from one UNIX system to another, and you don't specify Binary mode, any two-byte sequence that looks like CR+LF is converted to just LF on the receiving side. XMODEM (and Kermit for that matter) convert ASCII data to a standardized transport format, converting UNIX new-lines (LFs) to CR+LF before sending. The receiving system performs the reverse operation, converting CR+LF to LF, wherein lies the problem.

This can burn you with FTP as well. Many, if not most, FTP servers default to ASCII mode for transfers, unless you or your FTP client select Binary mode. Some FTP clients may have no facility for specifying Binary mode to the server. Thus, downloading things like compressed archives sometimes doesn't work. Binary is not the default with FTP-- it may appear to be, but each client/server has its own values. When in doubt, specify Binary.


One way to control the speed of transmission between two devices is through a handshake, an exchange of characters between a transmitter and a receiver that postpones transmission until the receiver is ready to receive the data. For example, XON/XOFF and ENQ/ACK flow control are handshakes.

Flow Control

Whenever you have two devices communicating over the network you have the problem of what to do if one transmits data faster than it can be received by the other. So you need flow control, the pacing of data in a transmission to ensure that the receiver can process what has already been sent before transmitting more. The goals of flow control are data integrity and transmission throughput.

XON/XOFF flow control is the most common method for serial connections. XON/XOFF, also called Dc1/Dc3 and ^Q/^S, is used on MPE and HP-UX. If data is coming too fast, you send an XOFF character (decimal 19, aka DC3 or Control-S). The sender stops sending until you send it an XON character (decimal 17, aka DC1 or Control-Q). Of course there are a few corner cases that make it more complicated, but that is the essence of XON-XOFF flow control. If the sender misses the XOFF, data overrun occurs. If the sender misses the XON, the communication port is hung. On HP terminals you can enable XON-XOFF for "Receive Pacing" and "Send Pacing." To enable XON/XOFF for data transmitted by your HP-UX port, do stty ixon. For XON/XOFF on received data, do stty ixoff. You can use XON/XOFF to manually pause transmission to your screen. Press ^S to stop the output, then ^Q later to resume it.

Hardware Flow Control. Most serial communications uses software Flow Control, but there is an alternative: hardware handshaking. For example, the clear-to-send signals on the RS-232 line are often used to slow the data flow from a modem to a PC. Specifically, RTS is used by a DTE to stop the DCE and CTS is used by the DCE to stop the DTE.

One pressing reason for selecting hardware handshaking is that some modems cannot deal correctly with binary data streams that contain characters which look like DC1/DC3. Hardware handshaking is also known as Out-of-Band flow control, because the signals are generated and observed outside the flow of the data.

Care must be taken when enabling hardware handshaking. Both parties have to agree and be compatibly configured before you start. Software flow control is re-active. Things proceed normally until one party says "Stop!". Hardware flow control is pro-active. You do not start transmitting until you receive the Go signal. If you never get it, you never start. Fortunately, with most modems the hardware handshake rules are not turned On until a connection has been established. You can do most AT commands regardless of the handshake rules in effect--otherwise how would you enable or disable hardware flow control?

ENQ/ACK is a proprietary method of flow control used on Classic MPE V systems and is still built-in to most HP terminals and enabled by default. The transmitter sends an ENQ (Enquiry, decimal 5, Control-E) every 80 characters (or so). When the receiver is ready for more data, it replies with an ACK (Acknowledge, decimal 6, Control-F). If there is no reply in 10 seconds, MPE V resumes printing printing (Term Type 10). If you disable ENQ/ACK on your terminal, you will see output interspersed with pauses. MPE/iX and HP-UX normally use XON/XOFF Flow Control instead of ENQ/ACK.

HP's Serial Read Trigger: The Host Prompt

In character mode, the MPE FREAD intrinsic sends a DC1 (decimal 17, XON) to the terminal when it is ready to receive data. It expects the terminal to suspend transmission after sending a Return and wait for another DC1. The user is not supposed to start typing until the DC1 has been received, which is invisible. On a slow system, users discover that they can sometimes type several characters between the appearance of the program prompt and the receipt of the XON by the terminal.

On HP-UX and when MPE typeahead is enabled, the DC1 trigger is not essential. If the user types when the system is not ready for input, the host system saves the characters in a buffer for the next read request. When the host program can handle them, the saved characters are processed (whether they are echoed to the terminal at that time is an option).

Some HP-compatible terminals, terminal emulators, and black-box builders have taken advantage of HP's DC1 read trigger to implement typeahead external to the host system. If the user types before the DC1 trigger is received, the external typeahead mechanism saves the characters and transmits them when it sees the DC1. Randy Medd explains it thus:

The DC1 (XON) used by MPE isn't, strictly speaking, a flow control mechanism, since it isn't matched with a DC3. There is an implied DC3 (XOFF) whenever the FREAD terminates, usually on receipt of a carriage Return (CR). That's how our Type Ahead Engines and Attachmate type-ahead work. If you turn this upside-down and sideways, you can see the similarity between the DC1/CR pair and ENQ/ACK. In the steady state, when data is flowing from the HP 3000 to a terminal, the ACK works much like the DC1 - the system won't start transmitting to the terminal until it sees the ACK. The system transmits data up to, and including, the ENQ, at which point it stops, awaiting the next ACK "trigger." Similarly, in the other direction, the terminal doesn't (usually!) start transmitting (typing) until it sees the DC1. The terminal then transmits data up to, and including, the CR, at which point it stops, awaiting the next DC1.

When switching between MPE and HP-UX systems on the same terminal or emulator, you can have problems. If you enable "Use Host Prompt" for the MPE system, you hang on the HP-UX system. If you disable it, you can type ahead on the HP-UX system, but your Reflection type ahead mechanism no longer works (because it is no longer expecting a DC1 trigger). Of course, MPE now has an internal type ahead method that you can enable with set hptypeahead true.

HP's Block-Mode Protocols

Block mode causes a special flow control problem because the terminal sends a large amount of data as fast as it can. If the system does not have enough buffer space, some data will be lost. MPE V and HP-UX use a special DC1/DC2/DC1 Handshake for Block mode transfers while MPE/iX counts on the terminal to use XON/XOFF Transmit Pacing.

In the Classic DC1/DC2/DC1 handshake, the host system sends an DC1 (decimal 17, ^Q, XON) when input is allowed. When the user depresses a function key or the block-send key (Enter), the terminal sends a DC2 (decimal 18, ^R) to signal a pending input block. The terminal then waits for the system to allocate buffers for the transfer. When the host is ready, it sends an Escape sequence to home the cursor and lock the keyboard, followed by another DC1 (XON) to trigger the terminal into sending the block of data. If the second DC1 is never received, the port hangs. The G and H straps of the HP terminal control transmit handshaking. When using the DC1/DC2/DC1 handshake, they should look something like this: InhHndShk(G) NO. Inh DC2(H) NO. Since these are "inhibit" straps, NO actually means "yes, do the handshake". Surprisingly, HP-UX supports this classic MPE V handshake (for details, type man blmode).

MPE/iX on the PA-RISC systems doesn't use the DC1/DC2/DC1 handshake. Instead, the host enables a feature of the HP terminal which automatically does the HomeUp and Lock when the user presses Enter, then sends the block of data, whether the host is ready or not. If the host DTC (terminal controller) runs out of buffer space, it sends an XOFF to slow things down. For this to work, the terminal G and H straps must be set to inhibit handshaking: InhHndShk(G) YES. Inh DC2(H) YES. And of course you must have "Xmit Pacing: YES".


A packet is the unit of data transmitted on a network. It consists of the data, of course, plus control information that allows the computers on the network to determine whether to receive the data. For example, a packet header would contain origin, destination, length, and other information.

Packet switching is the process of routing and transmitting addressed packets over a network, or network of networks such as the Internet. Data packets headed for many different destinations can travel on the same network and are assembled in sequence at the receiving end. This is different from circuit connections, such as the telephone system, which connect locations on demand and gives them the exclusive use of a data circuit until they are done.


TCP and IP are actually two separate protocols, with separate responsibilities. Together with a few other protocols, TCP/IP constitutes the Internet Protocol Suite, the method by which the Internet can transmit data reliably anywhere in the world.

TCP stands for Transmission Control Protocol. This is a transport-level protocol that sits on top of IP. It provides a reliable full-duplex byte stream between processes, whether they reside on the same machine or different machines. TCP is responsible for things like ensuring that the packets it transmits are received in the same order in which they were sent out, and reconstructed into the original byte stream. This is important, since two adjacent packets could take different routes to the same destination. Also, remember that TCP is concerned only with delivering a stream of bytes. Any meaning associated with those bytes, such as organization into lines or files, must be handled by a higher-level protocol.

IP stands for Internet Protocol and is a public standard network layer protocol. That means it is responsible for getting data from one machine to another, but isn't responsible for the assembling of that data for the receiving process. IP is a lower-level protocol than TCP.

Berkeley Sockets

A socket is an interface between an application and a network transport layer. It allows communication between processes on different host systems. Berkeley Sockets is an API developed at UC Berkeley. It is used as a standard socket interface to TCP/IP, although there are several flavors of sockets. It is sometimes also known as TCP Sockets. The Sockets API allows a process to listen on a port for requests for connection from processes on other machines (or the same machine). Then a connection can be negotiated and full-duplex communication can begin. Sockets is the basis for popular Internet services such as the World Wide Web.

Windows Sockets is a standard API which allows a process to communicate with another process using Berkeley Sockets. Windows Sockets comes packaged on Windows 3.1 as a winsock.dll file. There are many competing winsocks, which differ in speed, reliability, convenience, and even features (in spite of the standard!).

[Robelle] [SmugBook] [Index] [Net] [Prev] [Next]