TCP/IP Services and Client/Server Architecture

TCP/IP Services and Client/Server Architecture

By design, a typical Internet service is implemented in two parts—a server that provides information and one or more clients that request information. Such client/server architecture has been gaining popularity as an approach for implementing distributed information systems. The client/server architecture typically consists of a collection of computers connected by a communication network. The functions of the information system are performed by processes (computer programs) that run on these computers and communicate through the network.

In recent years, the client/server architecture has become commonplace as the mechanism that brings the centralized corporate databases to desktop PCs on a network. In a client/server environment, one or more servers manage the centralized database and clients gain access to the data through the server.

Like a database server, an Internet service such as FTP or the Web also provides a service using the client/server model. A user who wants to access information uses a client (for example, a Web browser) to connect to a server and download information (for example, Web pages from a Web server). In this case, the Web server acts as a database manager—the data are the HTML files (Web pages).

Insider Insight 

Client/server architecture requires clients to communicate with the servers. That’s where TCP/IP comes in—TCP/IP provides a standard way for clients and servers to exchange packets of data. The next few sections explain how TCP/IP-based services communicate. From this discussion, you learn about the port numbers associated with many well-known Internet services.

Understanding TCP/IP and Sockets

Client/server applications such as Web servers and browsers use TCP/IP to communicate. These Internet applications perform TCP/IP communications using the Berkeley Sockets interface (so named because the socket interface was introduced in Berkeley UNIX around 1982). The sockets interface consists of a library of routines that an application developer can use to create applications that can communicate with other applications on the Internet. There is even a Windows Sockets API (application programming interface—a fancy name for a library of programming functions that can be called by C programs) modeled after the Berkeley Sockets interface. The Winsock interface, as it’s known, provides a standard API that Windows programmers can use to write network applications.

Even if you do not write network applications using sockets, you have to use many network applications. Knowledge of sockets can help you understand how network-based applications work, which, in turn, helps you find and correct any problems with these applications.

Socket Definition

Network applications use sockets to communicate over a TCP/IP network. A socket is an abstraction that represents an endpoint of a connection. Because a socket is bidirectional, data can be sent as well as received through it. A socket has three attributes:

  • The network address (the IP address) of the system

  • The port number identifying the process (a process is a computer program running on a computer) that exchanges data through the socket

  • The type of socket (such as stream or datagram) identifying the protocol for data exchange

Essentially, the IP address identifies a network node, the port number identifies a process on the node, and the socket type determines the manner in which data is exchanged—through a connection-oriented or connectionless protocol.

Connection-Oriented Protocols

The socket type indicates the protocol being used to communicate through the socket. A connection-oriented protocol works like a normal phone conversation. When you want to talk to your friend, you have to dial your friend’s phone number and establish a connection before you can have a conversation. In the same way, connection-oriented data exchange requires both the sending and receiving processes to establish a connection before data exchange can begin.

Insider Insight 

In the TCP/IP protocol suite, TCP—Transmission Control Protocol—supports a connection- oriented data transfer between two processes running on two computers on the Internet. TCP provides a reliable two-way data exchange between processes.

As the name TCP/IP suggests (and as the “Network Protocols” section indicates), TCP relies on IP—Internet Protocol—for delivery of packets. IP does not guarantee delivery of packets, nor does it deliver packets in any particular sequence. IP does, however, efficiently deliver packets from one network to another. TCP is responsible for arranging the packets in the proper sequence, detecting whether or not errors have occurred, and requesting retransmission of packets in the case of an error.

TCP is useful for applications that plan to exchange large amounts of data at a time. In addition, applications that need reliable data exchange use TCP. For example, FTP uses TCP to transfer files.

In the sockets model, a socket that uses TCP is referred to as a stream socket because TCP provides an illusion of a continuous stream of data.

Connectionless Protocols

A connectionless data-exchange protocol does not require the sender and receiver to explicitly establish a connection. It’s like shouting to your friend in a crowded room—you can’t be sure if your friend hears you, and if you can’t tell whether or not he or she heard you, after a certain amount of time, you shout again to see if he or she hears you.

Insider Insight 

In the TCP/IP protocol suite, the User Datagram Protocol (UDP) provides connectionless service for sending and receiving packets known as datagrams. Unlike TCP, UDP does not guarantee that datagrams ever reach their intended destination. Nor does UDP ensure that datagrams are delivered in the order they have been sent.

UDP is used by applications that exchange small amounts of data at a time or by applications that do not need the reliability and sequencing of data delivery. For example, SNMP (Simple Network Management Protocol) uses UDP to transfer data. UDP is generally used by applications where each message is largely self-contained so that even if some of the messages don’t get through, it’s not critical.

In the sockets model, a socket that uses UDP is referred to as a datagram socket.

Sockets and the Client/Server Model

It takes two sockets to complete a communication path. When two processes communicate, they use the client/server model to establish the connection. The server application listens on a specific port on the system—the server is completely identified by the IP address of the system where it runs and the port number where it listens for connections. The client initiates connection from any available port and tries to connect to the server (identified by the IP address and port number). Once the connection is established, the client and the server can exchange data according to their own protocol.

The sequence of events in sockets-based data exchanges depends on whether the transfer is connection oriented (TCP) or connectionless (UDP).

Insider Insight 

For a connection-oriented data transfer using TCP sockets, the server “listens” on a specific port, waiting for clients to request connection. Data transfer begins only after a connection is established. The server is a program that responds when a connection is attempted at a certain port.

For connectionless data transfers using UDP sockets, the server waits for a datagram to arrive at a specified port. The client does not wait to establish a connection; it simply sends a datagram to the server.

Performing Client/Server Communications with TCP/IP

Client/server applications use the following basic steps to exchange data in a TCP/IP network:

  1. Create a socket. If the socket already exists, you can skip this step.

  2. Bind an IP address and port to the socket.

  3. Listen for connections if the application is a server using a stream socket.

  4. Establish connection if the application is a client using a stream socket.

  5. Exchange data.

  6. Close the socket when done.

Connectionless sockets (that implement data transfer using UDP) do not require Steps 3 and 4.

Regardless of whether it’s a server or a client, each application first creates a socket. Then it associates (binds) the socket with the local computer’s IP address and a port number. The IP address identifies the machine (where the application is running), and the port number identifies the application using the socket.

Exploring Internet Services and Port Numbers

The TCP/IP protocol suite has become the lingua franca of the Internet because many standard services are available on all systems that support TCP/IP. These services make the Internet tick by enabling the transfer of mail, news, and Web pages. These services go by well-known names such as the following:

  • DHCP (Dynamic Host Configuration Protocol) is for dynamically configuring TCP/IP network parameters on a computer. DHCP is primarily used to assign dynamic IP addresses and other networking information such as name server, default gateway, domain names that are needed to configure TCP/IP networks. The DHCP server listens on port 67.

  • FTP (File Transfer Protocol) enables the transfer of files between computers on the Internet. FTP uses two ports—data is transferred on port 20, while control information is exchanged on port 21.

  • HTTP (HyperText Transfer Protocol) is a recent protocol for sending HTML documents from one system to another. HTTP is the underlying protocol of the Web. By default, the Web server and client communicate on port 80.

  • SMTP (Simple Mail Transfer Protocol) is for exchanging email messages between systems. SMTP uses port 25 for information exchange.

  • NNTP (Network News Transfer Protocol) is for distribution of news articles in a store-and-forward fashion across the Internet. NNTP uses port 119.

  • Telnet enables a user on one system to log in to another system on the Internet (the user must provide a valid user ID and password to log in to the remote system). Telnet uses port 23 by default. However, the Telnet client can connect to any specified port.

  • SNMP (Simple Network Management Protocol) is for managing all types of network devices on the Internet. Like FTP, SNMP uses two ports: 161 and 162.

  • TFTP (Trivial File Transfer Protocol) is for transferring files from one system to another (typically used by X terminals and diskless workstations to download boot files from another host on the network). TFTP data transfer takes place on port 69.

  • NFS (Network File System) is for sharing files among computers. NFS uses Sun’s Remote Procedure Call (RPC) facility, which exchanges information through port 111.

A well-known port is associated with each of these services. The TCP protocol uses this port to locate a service on any system. (A server process—a computer program running on a system—implements each service.)

Note that many applications use specific port ranges that are outside the typical list of well-known ports.

As with the /etc/hosts file, which stores the association between host names and IP addresses, the association between a service name and a port number (as well as a protocol) is stored in another text file, named /etc/services. Following is a small subset of lines from the /etc/services file in a Red Hat Linux system:

# /etc/services:
# $Id: services,v 1.32 2003/01/09 17:56:30 dwalsh Exp $
# Network services, Internet style
# Note that it is presently the policy of IANA to assign a single 
# well-known port number for both TCP and UDP; hence, most 
# entries here have two entries even if the protocol doesn't 
# support UDP operations.
# Updated from RFC 1700, ``Assigned Numbers'' (October 1994).  
# Not all ports are included, only the more common ones.
# The latest IANA port assignments can be gotten from
# The Well Known Ports are those from 0 through 1023.
# The Registered Ports are those from 1024 through 49151
# The Dynamic and/or Private Ports are those from 49152 
# through 65535.
# Each line describes one service, and is of the form:
# service-name  port/protocol  [aliases ...]   [# comment]
tcpmux          1/tcp    # TCP port service multiplexer
tcpmux          1/udp    # TCP port service multiplexer
ftp-data        20/tcp
ftp-data        20/udp
# 21 is registered to ftp, but also used by fsp
ftp             21/tcp
ftp             21/udp          fsp fspd
ssh             22/tcp               # SSH Remote Login Protocol
ssh             22/udp               # SSH Remote Login Protocol
telnet          23/tcp
telnet          23/udp
# 24 - private mail system
smtp            25/tcp          mail
smtp            25/udp          mail
... many lines deleted ...

You’ll find browsing through the entries in the /etc/services file to be instructive because they show the breadth of networking services available under TCP/IP.

Insider Insight 

Note that port number 80 is designated for WWW service. In other words, if you set up a Web server on your system, that server listens to port 80. By the way, IANA—the Internet Assigned Numbers Authority (—is responsible for coordinating the assignment of port numbers below 1,024.

Running the xinetd Superserver

The client/server model requires that the server be up and running before a client makes a request for service. A simplistic idea would be to run all the servers and have them listen to their respective ports all the time. However, this idea is not practical because each server process would use up system resources in the form of memory and processor time. Besides, you don’t really need all the services up and ready at all times. A smart solution to this problem is to run a single server, xinetd, which listens to all the ports, then starts the appropriate server when a client request comes in.

Insider Insight 

The xinetd server is a replacement for an older server named inetd but with improved accesses control and logging. The name xinetd stands for extended inetd. You can learn more about xinetd by visiting

Learning How xinetd Works

The xinetd server is designed to monitor the ports for the services it is configured to start. When a client requests connection to one of the monitored ports, xinetd starts the corresponding server. The client then directly communicates with that server while xinetd goes on to listening to the ports again. For example, when a client tries to connect to the Telnet port, xinetd starts the Telnet server and lets it communicate directly with the client (and the Telnet server exits when the client disconnects). xinetd also logs the connection requests in a log file based on settings in its configuration file.

Here is the listing of files in the /etc/xinetd.d directory on a typical Red Hat Linux system:

ls /etc/xinetd.d
chargen      daytime-udp  imap   kotalk  rexec   servers   telnet
chargen-udp  echo         imaps  ktalk   rlogin  services  time
cups-lpd     echo-udp     ipop2  ntalk   rsh     sgi_fam   time-udp
daytime      finger       ipop3  pop3s   rsync   talk

Each file specifies the attributes for one service. As this listing shows, there are more than two dozen services that xinetd can start. Whether all the services are enabled or not, depends on the settings in each configuration file.

Understanding the xinetd Configuration Files

For example, the following listing shows the contents of the /etc/xinetd.d/telnet file, which specifies the xinetd configuration for the telnet service:

# description: The Telnet server serves Telnet sessions; it uses
#       unencrypted username/password pairs for authentication.
service telnet
        flags           = REUSE
        socket_type     = stream
        wait            = no
        user            = root
        server          = /usr/sbin/in.telnetd
        log_on_failure  += USERID
        disable         = yes

The filename (in this case, telnet) can be anything; what matters is the service name that appears next to the service keyword in the file. In this case, the line service telnet tells xinetd the name of the service. xinetd uses this name to look up the port number from the /etc/services file. If you use the grep command to look for telnet in the /etc/services file, here’s what you’ll find:

grep telnet /etc/services
telnet          23/tcp
telnet          23/udp
rtelnet         107/tcp                         # Remote Telnet
rtelnet         107/udp
telnets         992/tcp
telnets         992/udp

As the first two lines that begin with telnet show, the port number of the Telnet service is 23. This tells xinetd to listen to port 23 for Telnet service requests.

The attributes in the /etc/xinetd.d/telnet file, enclosed in curly braces, have the following meanings:

  • The flags attribute provides specific instructions about how to run the servers that xinetd starts. The REUSE flag means that the service is left running even if xinetd is restarted. Note that the REUSE flag is now implicitly assumed to be set for all services.

  • The socket_type attribute is set to stream, which tells xinetd that the Telnet service uses a connection-oriented TCP socket to communicate with the client.

  • For services that use the connectionless UDP sockets, this attribute would be set to dgram.

  • The wait attribute is set to no, which tells xinetd to start a new server for each request. If this attribute is set to yes, xinetd waits until the server exits before starting the server again.

  • The user attribute provides the user ID that xinetd uses to run the server. In this case, the server runs the Telnet server as root.

  • The server attribute specifies the program to run for this service. In this case, xinetd runs the /usr/sbin/in.telnetd program to respond to requests for Telnet service.

  • The log_on_failure attribute tells xinetd what information to log when it cannot start a server. In this case, the attribute appends the USERID flag to the default setting of HOST (set through the defaults block in the /etc/xinetd. conf file). The result is that if the Telnet service fails, xinetd logs the name of the remote host that requested the service as well as the user ID of the remote user.

  • The disable attribute turns off the service if it’s set to yes. By default the disable attribute is set to yes and Telnet is turned off.

Starting Standalone Servers

Although starting servers through xinetd is a smart approach, xinetd is not efficient if a service has to be started very often. The Web server typically has to be started often because every time a user clicks on a link on a Web page, a request arrives at the Web server. For such high-demand services, it’s best to start the server in a standalone manner. Such standalone servers are designed to run as daemons—processes that run continuously. That means the server listens on the assigned port; whenever a request arrives, the server handles it by making a copy of itself. In this way, the server keeps running forever. A more efficient strategy, used for Web servers, is to run multiple copies of the server and let each copy handle some of the incoming requests.