PennNet parity - Penn Printout, Apr 1992

The University of Pennsylvania's Online Computing Magazine

April 1992 - Volume 8:7

Network technology: PennNet parity

By John Dotts Hagan and Randall Couch

Unlike many dial-up services, such as commercial bulletin boards, PennNet specifies standard asynchronous communications settings that include the use of parity-specifically even parity after seven databits (7E). What exactly is parity? Why does PennNet support it? This article explores the answers to these questions. The accompanying sidebar describes some occasions when more experienced network users might want to use other settings, and explains how to change the settings for individual PennNet connections.

Timing is everything

In typical asynchronous communication, data is sent with varying intervals of time between eight-bit bytes (each byte representing an alphanumeric character or other data), rather than being synchronized against a clock. That means that the receiving device needs a way to tell when each byte of data starts and stops. The beginning of each byte is signalled by a "start bit". Since the use of a start bit is required, it is not usually mentioned in the shorthand description of communications settings. The start bit is followed by eight bits that can carry data, and then by either one or two "stop bits" to signal the end of the byte. Schemes for representing alphanumeric characters vary in how many of the eight available databits they use. ASCII (American Standard Code for Information Interchange), the scheme that has been widely used for communication between hosts and dumb terminals, is a seven-bit scheme that makes no use of the eighth bit.

Making use of the eighth bit

Parity is a method for detecting transmission errors that makes use of the unused eighth bit in the ASCII scheme. It works like this: If you think of signalling pulses as zeros and ones, the transmitting device counts the number of ones in each seven-bit ASCII character. It then puts either a zero or a one in the eighth position so that the sum of ones in each byte is always even or always odd. Each byte maintains the parity (oddness or evenness) specified in the communications settings. So if the receiving device "hears" a byte with incorrect parity, it knows a transmission error has occurred. Parity can be set to either odd or even; even is far more common.

Parity is the only mechanism by which most dumb terminals (or software emulating dumb terminals) can detect transmission errors. Since the initial priority for PennNet's asynchronous network (the ISN, which provides the DIAL: prompt) was terminal-host communication, a standard setting of seven databits with even parity (7E) was chosen to preserve the valuable error-detection function for dumb terminals.

8N: Not so dumb

So far, so good. The trouble starts when you want to transmit binary data, which uses all eight databits to carry information, leaving no parity bit. Many communications protocols, such as file transfer protocols and those for graphics terminal emulation, transmit binary data composed of eight databits, and provide their own error detection- and correction-schemes. These protocols either require, or operate most efficiently with, a setting of eight databits, no parity (8N). Kermit, PennNet's "official" asynchronous file transfer protocol, offers the ability to send binary data encoded in seven-bit ASCII, although it is less efficient than Kermit's eight-bit file transfer mode.

Never the twain shall meet

PennNet's ISN network is flexible enough to accommodate 8N under certain conditions (see sidebar). However, you cannot normally use seven-bit and eight-bit protocols in the same session, for example, to emulate a dumb terminal and then to transfer a binary file using a file transfer protocol requiring eight databits, such as Xmodem. Communications settings are one of the defining parameters of an asynchronous connection and are difficult to change in the middle of a session. Thus, you can't optimize settings for dumb terminal error detection and binary file transfer in the same asynchronous session.

For most dumb terminal-host communications, then, you'll want to stick with plain vanilla-7E. If you require more advanced asynchronous communications, consult the sidebar below for some alternatives.

Sidebar: 8N

PennNet's standard asynchronous communication settings are seven databits, even parity (7E). Some uses of PennNet, however, require eight databits, no parity (8N). Here are two examples:

Certain file transfers. Some microcomputer users have communications software packages with Xmodem-which requires 8N-embedded as the file transfer protocol. Others may choose to use Xmodem or Kermit in its 8-bit mode for their greater efficiency in transferring binary files.
Access to IP services (normally delivered on campus via Ethernet connections) over asynchronous lines. DCCS staff are currently working to develop the capability for PennNet to transmit SLIP (Serial Line IP). SLIP allows IP protocols to be transported by asynchronous devices and networks (including telephone lines), although at lower speeds than Ethernet provides. Dial-in users would employ 8N settings to access SLIP, enabling them to take advantage of feature-rich services such as FTP file transfer and Internet electronic mail (SMTP protocol).

To venture beyond standard 7E settings and make use of such services, here's what you need to know:

ISN (DIAL: prompt) connections are preset for 7E only during the "DIAL:" interaction. That is, the ISN sends you prompts and error messages using 7E. It will accept responses to the prompts using 7E or 8N, and once the host connection is established, it will transport either 7E or 8N. So if you set your terminal emulator to 8N after you see the DIAL: prompt, you should be able to communicate with a host, provided it doesn't want parity. Dedicated peripherals, such as printers, can also be set up with point-to-point asynchronous connections set to 8N.

Terminal server (annex:) connections are more specific about parity. Terminal servers usually connect to hosts via the Telnet protocol, which defines no parity and has its own error checking scheme. The terminal server can use either 7E or 8N to communicate with the user's terminal. Terminal server connections on campus can be set to the parameters requested by the user. If the user doesn't specify a setting, the default is 7E-consistent with the ISN network. Once you get an annex: prompt on your screen, however, your can change the settings for your port to 8N by entering stty bchar 8 parity none. To change it back, enter stty bchar 7 parity even. Remember, these settings only configure your PennNet connection; you still need to reset your terminal emulator settings to match them.

JOHN DOTTS HAGAN is Manager of Network Operations for DCCS and RANDALL COUCH is a Senior Technical Writer for DCCS/UMIS Publications.