Porting Serial I/O Applications to Distributed Environments

Michael Harold

Many existing vertical market applications were originally developed for a centralized computing environment which supported text-based terminal and printer devices via multi-port boards or terminal servers. The device drivers for most multiport boards were -- and still are -- supplied by the manufacturer of the boards and require "hard" connections for each serial device defined by the UNIX OS. Porting such applications to network environments can be a headache for application developers and systems administrators since, although the data may continue to reside on a central server, terminal devices may be distributed across a wide geographic area. This article describes a method for porting multiport-based serial applications to a distributed environment using TCP/IP programs and services.

It is possible to convert a centralized, multi-user "multiport" application to a distributed network application by creating TCP/IP-based links between one or more "communications" servers and a single "application" server which contains the application software. This is a less expensive solution than one requiring hubs and a network card for each terminal and printer in the LAN or WAN environment. The chief advantage of this approach is the ability to migrate to a network environment without having to modify the original application.

It is important to establish transparent connections between the application and communications servers in order to provide a single "point-of-entry" to the system. This means that a user is only required to login once to gain access to the application. Access to remote print services should also be transparent to the user. Methods to accomplish this are discussed in detail.

TCP/IP Services

TCP/IP is a set of protocols which provide network and communications services for heterogeneous computing environments. The data communications model for TCP/IP consists of three layers: The Network Access layer, the Host-to-Host Transport layer, and the Application layer.

The Network Access layer supports those protocols necessary to provide data communications at the hardware level among devices directly attached to the network.

The Host-to-Host or Transport layer consists of two procotols whose purpose it is to deliver IP (Internet Protocol) datagrams from one node to another on the network. The Transmission Control Procotol (TCP) provides end-to-end error detection and correction. It is the underlying Transport layer for services such as ftp, telnet, and smtp. The User Datagram Protocol (UDP) has less overhead than TCP and is therefore faster. UDP is the Transport layer for services such as snmp and nfs.

The Application layer lies on top of the Transport layer and provides application-specific communications services. The application services I will be using are rlogin and lpr. These services will be set up on the application server and on each of the communications servers. The setup procedures for the application server and the communications server(s) are basically the same.

Setting Up a Communications Server

I won't describe in detail here the installation procedure for a serial multiport product or the TCP/IP software. For the purposes of this article, Iassume some experience with terminal communications using serial multi-port cards and/or TCP/IP services. Moreover, serial communications are discussed in most UNIX system administration guides. An excellent guide to UNIX network communications is TCP/IP Network Administration by O'Reilly and Associates.

Once the TCP/IP software is installed on both the communications and application servers, the servers can be directly attached to the network via hubs or transceivers. It is also possible to connect the communications server to the application server using broadband telecommunications services such as ISDN.

This discussion assumes that the multiport board and the TCP/IP product have been successfully installed on the communications server. Each communications server should have a multiport card and a network card. The terminals and printers should be installed as serial devices controlled by the multiport device driver(s). After the network card and TCP/IP are installed, certain files should be examined to ensure that they contain the appropriate entries.

The /etc/services File

The services file assigns "port numbers" to specific application processes supported by TCP/IP. An example of a typical services file is shown in Listing 1. The first column identifies the application service. The second column identifies the port number and the transport protocol for that service. A port number is a 16-bit value that identifies the application service which is sending the data and the application service which is to receive the data. Most TCP/IP services are assigned the same port numbers, regardless of the OS vendor.

In the example /etc/services file, telnet is assigned port number 23 and printer is assigned port number 515. It is important that the application server and each of the communications servers have the same port number assigned for the rlogin (telnet) and lpr (printer) services.

The /etc/hosts File

The /etc/hosts file associates a logical device name (the IP address) with a physical device name (e.g., the ethernet address). This provides a means whereby each of the hosts or nodes on a network can identify those hosts with which they are to communicate. An example hosts file is shown in Listing 2. In this example the communications server is identified with the IP address 128.99.15.2 and the application server is identified with the address 128.99.15.1. The entry for localhost should be identical for each /etc/hosts file on the network.

Terminal Communications

The next requirement is a remote login service between the remote terminal device and the application server. The first step is to modify the user's .profile on the communications server to automatically login to the application server. An example .profile for the communications server is shown in Listing 3.

Once the user is logged into the communications server and the local environment variables and terminal attributes are established, a remote login procedure is executed. In this case the login is accomplished via the rlogin command. The rlogin command connects the terminal on the communications server to the application server using the telnet service. When you login as the same user on the application server you do not have to provide a password if there is a file called .rhosts in the user's home directory on the application server. The rlogin command sets the terminal type on the application server to match the terminal type given in the communications server's local TERM variable. This means that the termcap and/or terminfo entries for the terminal must be identical on the communications and application servers. The rlogin command is transparent to the communications server, so all character "echoes" occur only once.

Each user identified on a communications server must also be identified on the application server. The .profile is the same profile that would be used if the user were connected by a serial port to the application server.

When remote terminal connections are made using network services, a "pseudo-terminal" device name is assigned to each network connection established on the application server. Pseudo-terminals are virtual terminal devices which are allocated on a first-come, first-served basis -- much like a LIFO stack. This means that there is no guarantee that a user will be assigned the same pseudo-terminal device name each time he or she logs in. Many applications developed in multiport environments use the hardwired terminal port number to identify users and to assign printers. The application must be able to access the user's logname to identify the user and to assign printers. One way to accomplish this is to place the following command in the user's profile on the application server:

USER=`logname`; export USER

The USER environment variable can then be read by the application. If this is not possible, the logname can be echoed into a file and the file can be read by the application. A simple command to accomplish this is:

echo `logname` > user.asc

To avoid redundancy in the messages displayed by the application server, create a .hushlogin file containing the following commands in the user's home directory on the application server:

$ echo "" > .hushlogin
$ chmod 600 .hushlogin

Security is an important consideration for any network. Some texts discuss the use of the /etc/hosts.equiv file as a way of allowing transparent access between host machines, but this is not the best method. To prevent unauthorized access to the application server, you should create a file called .rhosts in the user's directory on the application server. This file identifies the trusted hosts and users for the account. An example entry in the .rhost file for user larry would be:

commserver larry

Only the root or end user should be able to read the .rhosts file.

A one-to-one correspondence must be established between the users on the communications server and the users on the application server. If multiple communications servers are used, each user name should be unique among all of the communication servers.

Printer Communications

The TCP/IP remote printer service is used to provide links between network printer devices on the application server and serial printer devices on the communications servers. A printer definition must exist on the communications and application servers for each printer defined on the communications server.

On the communications server, printers are identified as serial devices in the /etc/printcap file (the organization of the printcap file is discussed in Sys Admin, July/August 1995). An example printcap file for a communications server is shown in Listing 4.

On the application server, printers are identified in /etc/printcap as remote printers. An example printcap file for the application server is shown in Listing 5. Note the rm and rp entries: the rm identifies the remote host name to which the print job is to be sent, while the rp entry identifies the printer on the remote host on which the print job is to be printed. Setting up the printcap files in this way makes it possible to route a print job from the application through the network to a serial device connected to the communications server.

To avoid multiple banner pages and multiple form feeds, you may have to modify printer interfaces on the application server. A special printer interface called dumb.rmt is shown in Listing 6. This interface was created by copying an existing SCO UNIX interface for a "dumb" printer and removing all references to form feeds and banner pages.

Once print jobs are routed from the application to the communications server, it is possible to create filters for the printer on the communications server.

This method allows you to expand network topologies to include standalone terminals and PCs using local dial-up or leased lines to connect with communications servers, which in turn access a central application server using ISDN or T1 links. Further, there is nothing to prevent you from attaching multiport devices to the application server in order to provide local serial line access.

About the Author

Michael Harold is a systems analyst/programmer currently employed by Willis-Knighton Medical Center in Shreveport, Louisiana. He has worked with UNIXsystems for thirteen years as an educator, systems administrator, database administrator, and application developer. He can be reached at mharold@prysm.net.