IP_ =,,==u,=_= I i r w ~ ~ w w ~ ~iJ w ~ w

Communications protocol for dumb terminals A protocol for minicomputer access from remote multiple dumb terminals is described by Roger Evans

Dumb terminals are the norm for use with minicom- puters and will continue to be used until an inter- nationally-acceptable standard (perhaps based on CCITT X.25) is established. The paper describes an add- on communications protocol for users of multiple remote dumb terminals at a single office remote from the computer. The protocol has three basic elements, the error controller, the data concentrator, the multi- drop concentrator and the port concentrator.

The data-communications requirements of the mini- computer user differ from those of the large mainframe user in several important respects. Communication typically is over shorter distances - - 50-100 miles, rather than 1-2000 miles. Minicomputer users also typically have only one or two discrete data commun- ication links to remote offices, rather than a mult inode data-communications network, but the fundamental difference between the minicomputer user's data- communications requirements and those of the large mainframe user is that the minicomputer only supports, with very few exceptions, asynchronous dumb termi- nals, whereas the mainframe user typically expects his terminals to benefit from a built-in communicat ion protocol.

COMMUNICATIONS PROTOCOL

A communications protocol is a set of rules governing information flow in a communication'system. The rules include a definit ion of the block format or message envelope, which is used to packetize each message transmitted. The message envelope, as shown in Figure 1, usually contains special control characters to mark its beginning and end, along with an address with which messages can be directed to selected terminals. It may also include a sequence number and/or block check character, so that the receiving terminal may check the incoming message for errors. The protocol rules also def ine how a terminal acknowledges a message or, in the event it detects an error, how a terminal requests a retransmission.

Micom Systems Inc., 9551 Irondale Avenue, Chatsworth, CA9i 311, USA ©1980 Micon Systems Inc.

I Block check End of

> Figure 7. Message envelope

If a terminal conforms to one of the defined commu- nications protocQIs, such as IBM's Bisync or SDLC, it operates error-free, because it has the benefit of au- tomatic retransmission-on-error. It can also be multi- dropped, either individually or in clusters, with other terminals on a single line, because it can be selectively addressed or polled by the host computer (Figure 2.)

Although it is true that all of the minicomputer manufacturers do offer software support for one or more communication protocols, especially the popular IBM Bisync protocol, the software support is not des- igned for communication with terminals. It is designed for distributed-processing applications to permit the minicomputer to be connected to a large mainframe host, emulating an IBM Bisync terminal, for example. Alternatively, it is designed to facilitate computer-to- computer communications using packet-switched net- works (in the case of Data General) or DEC's Decnet network architecture. For the support of remote ter- minals, the minicomputer user is typically forced to use dumb terminals and configure his terminals so that there is one per computer port, as shown in Figure 3, thus losing the cost advantages of being able to put multiple terminals on one line and also losing the benefits of retransmission-on-error.

La~ main'man~ oor~x~r

Figure 2. Polled terminal configuration

224 0140-3664/80/050224-04502.00 © 1980 I PC Business P r e s s computer communications

Nvh I e Ifvl W I I P ' ~ I w ~ W W ~ ~ W ~ w

P r o t o c o l - " " " F i g u r e 3 .

Minicomputer

DUMB TERMINALS

A dumb terminal is a Teletype or Teletype compatible terminal. It operates asynchronously, even though it may operate at speeds up to 9 600 bit/d or higher. A dumb terminal uses no communication protocol or block format, it displays or prints data just as it receives it, without needing to recognize any predefined add- ressing sequence or to check for block errors. It trans- mits data directly as entered from the terminal key- board, or from its buffer, without adding any kind of block sequence or check character.

A dumb terminal is a protocol-less terminal. It may incorporate a microcomputer and an extensive control program which permits it to do intelligent local screen formatting, prompting, data field validation and range checking, but such a terminal is still dum b'if it is Teletype -compatible. Without a protocol, a terminal cannot be addressed, so it cannot be clustered or multidropped with other terminals on the same telephone line, and it has no means of assuring error-free data over telephone circuits. As a data-communications device, such a terminal is indeed dumb.

The reason why such terminals are the rule for minicomputers and the exception for mainframes is twofold.

First, whereas terminals in the batch-oriented en- vironment of the mainframe computer are normally remote from the computer site, the interactive, transac- tion-processing design philosophy of the minicom- puter manufacturers means that terminals are the sole means of computer access to local users, as well as remote users. Most of these terminals are hard-wired to the minicomputer, not connected over telephone lines, so they do not need retransmission-on-error or line-sharing capabilities.

Second, there is no standard communications pro- tocol. The communications protocols used for main- frames are the inventions of the manufacturers. Each protocol was defined by a single supplier so that terminals and computer software could be developed to support it. With such a large percentage of their terminals attached locally to the host minicomputer, the minicomputer manufacturers have not felt the need to develop and aggressively market a protocol of their own, except to enhance computer-to-computer com- munications. Furthermore, with so many of their users satisfied with the present arrangement, and so many of their OEMs and system houses anxious to preserve the freedom of choice which the Teletype-compatible industry standard provides, the minicomputer manu- facturers are not strongly motivated to invest in protocol of their own invention. Instead, they will wait for an international standard to materialize, perhaps based on the CCIFI X.25 protocol defined for access to international packet-switched networks. But such a standard will only evolve very slowly.

In the meantime, the dumb terminal will continue to thrive, but for the increasing number of minicomputer users who cannot tolerate the risk of undetected data- transmission errors and the telephone line costs asso- ciated with using multiple dumb terminals at a single office remote from the computer, reliable and cost- effective data communications may still be achieved using an appropriate external 'black box'. These black boxes provide an add-on communications protocol without requiring any changes to existing terminal hardware or minicomputer software, a concept used in the Micom, USA, ADLC* (Add-on Data Link Control).

ERROR CONTROLLER

The most basic element in the ADLC is the error controller. Retransmission-on-error is particularly re- quired at higher data-transmission speeds. Although error rates with 4 800 and 9 600 biffs modems on leased telephone lines are often as good as 1 bit in 106, the telephone company will provide assurances of no better than about 1 bit in 105 . At 4 800 biffs, this is equivalent to one error every 20 s. In reality , phone line errors occur more often as random bursts of noise, rather than very frequent single bit errors, but data trans- mission at 2 400 bit/s and above without retrans- mission-on-error is risky at best. For remote printing applications and, in particular, for graphics applications, error-free operation may be mandatory. In addition, data transmission at 2 400 bit/s and above requires synchronous modems, and dumb terminals are asyn- chronous.

The error controller is a low-cost'black box' designed to provide automatic retransmission-on-error as well as the mode conversion necessary to allow an asyn- chronous terminal to operate with synchronous mod-

* A D L C is a M i c o m t r ademark

vol 3 no 5 october 1980 225

nP.lultl-'- , . '¢ P i t . , = _ , I = r w ~ ~ m w v w w ~ v w l w ~w.~y

ems at 2 400 I~it/s and above (the error controller is also sometimes referred to as an intell igent async-to-sync- converter). The error controller is installed in pairs, one at each end of the leased telephone line, as shown in Figure 4.

Micom's Micro 500 error controller is also available in a special dial-up version which permits a full-duplex, asynchronous 'dumb' terminal to be used error-free with synchronous dial-up modems such as the Bell 201 C and 208 B which operate half-duplex at 2 400 or 4 800 bills. These dial-up error controllers must also serve as half-duplex-to-ful l-duplex-protocol-conver- ters. A typical configuration is shown in Figure 5.

In operation, the error controller receives data chara- cter-by-character from the terminal or computer port and transmits it in a block format, with block length determined by the number of characters received since the last block was transmitted. Blocks are transmitted continuously to minimize transmission delay. Each block starts with a header containing control infor- mation. This consists of the sequence number of the block and also the sequence number of the last block received correctly in the other direction. In the event the last block was received in error, a NAK (negative acknowledgement) block wil l be sent. The block header also includes a count to indicate the number of data characters in the block. The CRC is recalculated at the receiving end to ensure that the data block was received correctly. The CRC is the 16-bit result of a polynomial calculation performed on the bits in the block It provides only a 1 in 1012 probabil i ty that a CRC will check out correctlywith a block in error. It is claimed to reduce to almost zero the possibility that mult iple bit errors will be self-cancelling and thus avoid detection.

Any block received in error by the error controller is automatically retransmitted. The error controller em- ploys exactly the same error control technique used in communication protocols such as IBM's SDLC.

While a retransmission is taking place, incoming data from the terminal or computer is temporarily stored in

~ s Asynchronous 2 4 0 0 - 9 600 2 4 0 0 - 9 6 0 0

bits bits

Figure 4. Error controller configuration

A~r,~% cq-,ous F'DX bit/s 2 400-4 800 bit/s

Figure 5. Dial-up error controller configuration

Four channels 2 4 0 0 blt/s

Figure 6.

2400 txts or 4 8001~/s synchronous rno~ms

Four terminals at 2 4 0 0 10~/$ asynchronous

Data concentrator configuration

the error controller's buffer memory. Despite the fact that several hundred characters of memory are provid- ed, buffer overflow may occur, either because of ex- cessive retransmissions or a prolonged line outage.

However, options may be provided for DEC, Hew- lett--Packard, Data General and other minicomputer users which take advantage of the fact that these minicomputer systems will suspend transmission either on receipt of a special control character (X-Off), or on the dropping of the clear-to-send interface control signal. Transmission will resume when the system receives the X-On control character from the error controller or when it senses the raising of clear-to-send.

DATA CONCENTRATOR

The second element in the ADLC is the data con- centrator. The data concentrator uses statistical multi- plexing techniques to allow several dumb terminals to share a single telephone line, with one concentrator unit installed each end of the line (Figure 6). The device operates efficientlywith interactive CRTterminals, because it allocates the shared telephone line to each terminal dynamically, as needed, rather than on a predefined fixed basis. As a result, for example, the Micom Micro800 data concentrator can allow four CRTs, each operating at 2 400 bit/s, to share a single 2 400 bit/s line. In addition, the protocol used between the concentrators incorporates the same retransmission facility provided for single terminals by the error controller. Thus, the data con- centrator acts as an error controller and as a cluster controller for as few as two terminals, wi thout requiring any changes to the existing terminal hardware and minicomputer software. It also allows the asynchronous terminals to be used with high-speed synchronous modems.

In operation, the concentrator assembles characters from each active channel, bui lding variable length data blocks for transmission down the shared high-speed line. Transmitted block length is a function of the amount of data accumulated since the last block was transmitted. All data blocks received from the high- speed line are checked for errors, and retransmissions are requested for any block received incorrectly.

MULTIDROP CONCENTRATOR

The third element is the mult idrop concentrator. The mult idrop concentrator uses the same statistical multi-

226 computer communications

Four leminols

Eight ~ IVluffipoinf modem Full-duplex ]Concenltator] 1200-9 600 bit/s dato link I i rm

Figure 7. Mult idrop concentrator configuration

plexing techniques as the data concentrator, but be- cause it can be configured in a mul t ipoint configuration, it allows individual dumb terminals and dumb terminal clusters to be mult idropped at different locations to share a single mult ipoint telephone line.

The typical mult idrop concentrator system links mul- tiple regional offices with a central computer. In the example shown in Figure 7, the master concentrator unit at the computer site is configured with eight channels, each of which provides an apparently point- to-point transparent connection to a terminal in one of the regional offices. Regional offices are equipped with node concentrator units, configured with one, two or four channels.

In operation, the master concentrator polls the re- mote node units at high-speed, accepting mult iplexed inbound data from terminals at each site and delivering mult iplexed outbound data addressed to individual terminals at each site. The mult ipoint data-link operates synchronously at speeds to 9 600 bit/s, but speeds of 2 400 or 4 800 bit/s are most typical. The individual dumb terminals mult iplexed by the node concentrator at each site may operate at almost any asynchronous data rate up to 4 800 bills.

PORT CONCENTRATOR

The last element is the port concentrator. Whereas all of the other elements require no changes to existing hardware and software (they preserve the one-to-one relationship between each terminal and its associated port on the minicomputer) in some configurations ports may be limited. Some type of port-sharing device may be desirable.

The benefit of the true communications protocol, supported in software on the host computer, is that it allows mult iple terminals to be pol led using a single

computer port as well as a single telephone line. But unless special software resides in the host computer, it is not possible to support mult iple terminals on a single port. The purpose of the port concentrator is to simplify the special software required.

The Micom Micro200 port concentrator is used in conjunction with a Micro800 data concentrator as shown in Figure 8.

The port concentrator functions as a single channel master data concentrator, al lowing one computer port to communicate with mult iple channels attached to a remote data concentrator using a simple asynchronous or synchronous protocol. It allows transmissions to and from the host computer to consist of simple lines of text, preceded by a terminal address.

The port concentrator performs more than half the work necessary to communicate directly with a remote data concentrator. As previously discussed, all dataflow between data concentrators is transmitted in numbered blocks, each terminated by a 16-bit CRC character. The port concentrator assumes full responsibil ity for the complex task of error control and only transfers error- free data blocks to the host computer. In addition, data buffering requirements caused by a backlog of data, owing to retransmissions or temporary line shortages on the link to the remote data concentrator, are handled automatically by the port concentrator.

The port concentrator also assumes responsibility for synchronization with the remote data concentrator. This is necessary even when there is no data activityto ensure rapid response and minimum delay whenever there is data to transmit. This need for constant synchronization might otherwise impose a significant burden on the host computer. The port concentrator assumes all of this burden.

As a device to economize on computer ports, the port concentrator has one advantage. Unlike the other elements, it does require special software support. This is unavoidable, however, if all terminals sharing the port need to be onl ine at all times. But for applicationswhich involve a session, where a terminal need only be onl ine for a period of a few hours at one time, other solutions are available which permit port sharing wi thout re- quiring any software changes.

Host Port computer concentrator

~chronous Or s mchronous 1200- 9 600 bills

I I

Full- duplex doto

Mod~n: 300-9 600

M ~ ~ data ~rminals

50-9 600 ~/$

Figure 8. Port concentrator configuration

vol 3 no 5 october 1980 227