Network Services

*********************************************************************
Network Services
by S. Lee Henry

You've undoubtedly heard the phrase "network services" used numerous
times. In this week's column, we're going to look at what a network
service is and how it's invoked.

To begin, let's simply list a few examples of network services. You're
probably familiar with most or all of these:

- telnet
- ftp
- sendmail
- httpd
- pop

These are only a sampling of the services that you're likely to find on
any Unix server, but they're fairly basic and generally well-known, so
they'll serve as good examples for our discussion.

"Network services" is a loosely defined term that describes services
that run on servers on a network and supply a service to clients. The
ftp service, for example, is not likely to be running on most client
systems, yet it's a common service on servers and allows users to upload
and download files. On the client side of an ftp connection, the user
types ftp (e.g., tftp jasper.nici.net) to make a connection
to the ftp server. The client process opens a connection, called a
"port", to the server. On the server side, another process is listening
on that port and answers the client request.

Here's a typical ftp scenario:
- a user on lj.nici.net starts an ftp session by entering the command
"ftp jasper.nici.net"
- the system opens a port, using a random port on the client (let's say
it uses port 12345) to connect to the ftp port on the server (port 21)
- the ftp server on the server receives the request for a connection
from the client
- the user issues requests to the ftp service, using the ls, cd, get,
and put commands
- the server process opens up additional connections as needed to manage
the data transfers
- the user ends his session by entering the command "bye"

client (port 12345) => server (port 21)

Many network services proceed in very similar fashion. The client side
makes a request and initiates a connection to the port associated with a
particular network service. The process "listening" on that port
responds. Eventually, the connection is closed.

Let's look at a POP session:
- a user is starting up an email application on his client system
- the email application makes a connection to the email server specified
in the user's configuration
- the email application then starts up a "dialog" with the server
- the email application says something like "user nici" and "pass
mypassword"
- the email application then proceeds to fetch mail messages for the
user and presents a brief synopsis of each message (probably just the
sender's email address and the subject line) to the user
- the user reads, replies and deletes messages
- the email application sends commands to the server to reflect the
user's activities
- if the user's configuration directs the application to "keep mail on
the server", it doesn't issue delete (ie., dele) commands - otherwise,
it does
- the email application updates its "view" of the user's email holdings
on the server as needed
- the user quits the email application and the application sends a
"quit" command to the server

Many network services do not "listen" for themselves but, instead,
employ the services of a another system service to do this for them.
That service, inetd, listens for requests on behalf of a number of
network services. If inetd gets a request for POP, for example, it
starts up the popper application, which manages the server side of the
dialog represented above.

Popper is, in fact, a service that might easily and commonly be run
either as a "daemon" process, which starts up when a system is booted,
and listens for requests or in response to requests from clients in
which inetd starts up the service on an "as needed" basis.

client (12345) => server (110)
client (12345) => inetd => POP

The inetd process itself is started at boot time. It reads its
configuration file, /etc/inetd.conf, to determine which ports it must
monitor and which services it must invoke to manage the requests it
receives.

If you look at the /etc/inetd.conf file on your server, you will see
many of the services that your server provides, the ports these services
run on and the full path name to the service. The following line is
typical:

pop3    stream  tcp     nowait  root    /usr/local/bin/popper popper

If the inetd service goes down (this is very rare), requests for any
service that inetd is supporting will go unanswered. For example, if the
inetd process of your server crashes, you will not be able to initiate
new telnet or POP sessions (if inetd is managing both), though existing
sessions will continue to operate since these are no longer dependant on
inetd.

Next Week: How to Check Your Network Connection

About the author
----------------
S. Lee Henry has been administering Unix systems for 15 years. Even so,
she describes herself as USL (Unix as a second language) and still
remembers enough English to write books and buy groceries. She lives on
a sailboat in Marin County, California and can be reached at
s.lee.henry@sunworld.com.

Jean Francois Sends...
President & CEO MagusNet, Inc.
MagusNet.com, MagusNet.Gilbert.AZ.US
CTO EBIZ Enterprises, Inc.
TheLinuxStore.com, TheLinuxLab.com, LinuxWired.net
480-778-1120 - Office
602-770-JLF1 - Cellular