Porting Serial I/O Applications to Distributed Environments
Many existing vertical market applications were originally
a centralized computing environment which supported
and printer devices via multi-port boards or terminal
device drivers for most multiport boards were -- and
still are -- supplied
by the manufacturer of the boards and require "hard"
each serial device defined by the UNIX OS. Porting such
network environments can be a headache for application
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
multiport-based serial applications to a distributed
TCP/IP programs and services.
It is possible to convert a centralized, multi-user
application to a distributed network application by
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
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
application and communications servers in order to provide
"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
this are discussed in detail.
TCP/IP is a set of protocols which provide network and
services for heterogeneous computing environments. The
communications model for TCP/IP consists of three layers:
Access layer, the Host-to-Host Transport layer, and
The Network Access layer supports those protocols necessary
data communications at the hardware level among devices
attached to the network.
The Host-to-Host or Transport layer consists of two
purpose it is to deliver IP (Internet Protocol) datagrams
from one node
to another on the network. The Transmission Control
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
faster. UDP is the Transport layer for services such
as snmp and nfs.
The Application layer lies on top of the Transport layer
application-specific communications services. The application
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
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
article, Iassume some experience with terminal communications
serial multi-port cards and/or TCP/IP services. Moreover,
communications are discussed in most UNIX system administration
An excellent guide to UNIX network communications is
Administration by O'Reilly and Associates.
Once the TCP/IP software is installed on both the communications
application servers, the servers can be directly attached
to the network
via hubs or transceivers. It is also possible to connect
communications server to the application server using
telecommunications services such as ISDN.
This discussion assumes that the multiport board and
the TCP/IP product
have been successfully installed on the communications
communications server should have a multiport card and
a network card.
The terminals and printers should be installed as serial
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
processes supported by TCP/IP. An example of a typical
services file is
shown in Listing 1. The first column identifies the
The second column identifies the port number and the
for that service. A port number is a 16-bit value that
application service which is sending the data and the
service which is to receive the data. Most TCP/IP services
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
application server and each of the communications servers
have the same
port number assigned for the rlogin (telnet) and lpr
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).
a means whereby each of the hosts or nodes on a network
those hosts with which they are to communicate. An example
hosts file is
shown in Listing 2. In this example the communications
identified with the IP address 188.8.131.52 and the application
identified with the address 184.108.40.206. The entry for
be identical for each /etc/hosts file on the network.
The next requirement is a remote login service between
terminal device and the application server. The first
step is to modify
the user's .profile on the communications server to
to the application server. An example .profile for the
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,
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
service. When you login as the same user on the application
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
means that the termcap and/or terminfo entries for the
terminal must be
identical on the communications and application servers.
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
When remote terminal connections are made using network
"pseudo-terminal" device name is assigned
to each network connection
established on the application server. Pseudo-terminals
terminal devices which are allocated on a first-come,
-- 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
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
USER=`logname`; export USER
The USER environment variable can then be read by the
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
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.
discuss the use of the /etc/hosts.equiv file as a way
transparent access between host machines, but this is
not the best
method. To prevent unauthorized access to the application
should create a file called .rhosts in the user's directory
application server. This file identifies the trusted
hosts and users for
the account. An example entry in the .rhost file for
user larry would
Only the root or end user should be able to read the
A one-to-one correspondence must be established between
the users on the
communications server and the users on the application
multiple communications servers are used, each user
name should be
unique among all of the communication servers.
The TCP/IP remote printer service is used to provide
network printer devices on the application server and
devices on the communications servers. A printer definition
on the communications and application servers for each
on the communications server.
On the communications server, printers are identified
as serial devices
in the /etc/printcap file (the organization of the printcap
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
remote printers. An example printcap file for the application
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
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
created by copying an existing SCO UNIX interface for
a "dumb" printer
and removing all references to form feeds and banner
Once print jobs are routed from the application to the
server, it is possible to create filters for the printer
This method allows you to expand network topologies
standalone terminals and PCs using local dial-up or
leased lines to
connect with communications servers, which in turn access
application server using ISDN or T1 links. Further,
there is nothing to
prevent you from attaching multiport devices to the
in order to provide local serial line access.
About the Author
Michael Harold is a systems analyst/programmer currently
Willis-Knighton Medical Center in Shreveport, Louisiana.
He has worked
with UNIXsystems for thirteen years as an educator,
administrator, database administrator, and application
developer. He can
be reached at firstname.lastname@example.org.