Network Services

[J. Francois]

*********************************************************************
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