Socket Programming with TCP

Socket Programming with TCP

As we have considered many important network applications, let's discover how network application programs are actually written. In this section we'll write application programs that use TCP; in the following section we'll write programs that use UDP.

Recall from "Principles of Network Applications" that several network applications consist of a pair of programs - a client program and a server program - residing in two different end systems. When these two programs are executed, a client and a server process are created, and these processes communicate with each other by reading  from and writing to sockets. When creating a network application, the developer's main task is to write the code for both the client and server programs.

There are two types of network applications. One type is an implementation of a protocol standard defined in, for instance, an RFC. For such an  implementation, the client and server programs must conform to the rules dictated by the RFC. For instance, the client program could be an implementation of the client side of the FTP protocol, explained in "File Transfer: FTP"; likewise, the server program could be an implementation of the FTP server protocol. If one developer writes code for the client program and an independent developer writes code for the server program, and both developers carefully follow the rules of the RFC, then the two programs will be able to interoperate. In fact, many of today's network applications involve communication between client and server programs that have been created by independent developers - for instance, a Firefox browser communicating with an Apache Web server, or an FTP client on a PC uploading a file to a Linux FTP server. When a client or server program implements a protocol defined in an RFC, it should use the port number associated with the protocol. (Port numbers were briefly discussed in "Principles of Network Applications". They are covered in more detail in "Transport Layer")

The other type of network application is a proprietary network application, In this case the application-layer protocol used by the client and server programs do not necessarily conform to any existing RFC. A single developer (or development team) creates both the client and server programs, and the developer has complete control over what goes in the code. But because the code does not implement a public domain protocol, other independent developers will not be able to develop code that interoperates with the application. When developing a proprietary application, the developer must be careful not to use one of the well-known port numbers defined in the RFCs.

In this and the next section, we study the key issues in developing a proprietary client-server application. During the development phase, one of the first decisions the developer must make is whether the application is to run over TCP or over UDP. Recall that TCP is connection oriented and provides a  reliable byte-stream channel through which data flows between two end systems. UDP is connectionless and sends independent packets of data from one end system to the other, without any guarantees about delivery.

In this section we develop a simple client application that runs over TCP; in the next section, we develop a simple client application that runs over UDP. We present these simple TCP and UDP applications in Java. We could have written the code in C or C++, but we opted for Java mostly because the applications are more neatly and cleanly written in Java. With Java there are fewer lines of code, and each line can be explained to the novice programmer without much difficulty. But there is no need to be frightened if you are not familiar with Java. You should be able to follow the code if you have experience programming in another language.

For readers who are interested in client-server programming in C, there are several good references available [Donahoo 2001; Stevens 1997; Frost 1994; Kurose 1996].

Socket Programming with TCP

Recall from "Principles of Network Applications" that processes running on different machines communicate with each other by sending messages into sockets. We said that each process was similar to a house and the processs socket is similar to a door. As shown in Figure 1, the socket is the door between the application process and TCP. The application developer has control of everything on the application-layer side of the socket; however, it has little control of the transport-layer side. (At the very most, the application developer has the ability to fix a few TCP parameters, such as maximum buffer size and maximum segment size.)

Processes communicating through TCP sockets

Now let's take a closer look at the interaction of the client and server programs. The client has the job of initiating contact with the server. In order for the  server to be able to react to the client's initial contact, the server has to be ready. This implies two things. First, the server program cannot be dormant - that is, it must be running as a process before the client attempts to start contact. Second, the server program must have some sort of door - more specifically, a socket - that welcomes some initial contact from a client process running on an arbitrary host. Using our house/door analogy for a process/socket, we will sometimes refer to the clients initial contact as "knocking on the welcoming door".

With the server process running, the client process can start a TCP connection to the server. This is done in the client program by creating a socket. When the client creates its socket, it specifies the address of the server process, namely, the IP address of the server host and the port number of the server process. Once the socket has been created in the client program, TCP in the client initiates a three-way hand-shake and establishes a TCP connection with the server. The thee-way handshake, which takes place at the transport layer, is completely transparent to the client and server programs.

During the three-way handshake, the client process knocks on the welcoming door of the server process. When the server "hears" the knocking, it creates a new door - more specifically, a new socket - that is dedicated to that particular client. In our example blow, the welcoming door is a ServerSocket object that we call the welcomeSocket. When a client knocks on this door, the program invokes welcomeSocket's accept ( ) method, which creates a new door for the client. At the end of the handshaking phase, a TCP connection exists between the client's socket and the server's new socket. Hereafter, we refer to the server's new, dedicated socket as the server's connection socket.

From the application's point of view, the TCP connection is a direct virtual pipe between the client's socket and the server's connection socket. The client process can send arbitrary bytes into its socket, and TCP guarantees that the server process will receive (through the connection socket) each byte in the order sent. TCP thus provides a reliable byte-stream service between the client and server processes. Moreover, just as people can go in and out the  same door, the client process not only sends bytes into but also receives bytes from its socket; likewise, the server process not only receives bytes from but also sends bytes into its connection socket. This is demonstrated in Figure 2. Because sockets play a main role in client/server applications, client/server application development is also referred to as socket programming.

Before providing our example client-server application, it is useful to discuss the concept of a stream. A stream is a sequence of characters that flow into or out of a process. Each stream is either an input stream for the process or an output stream for the process. If the stream is an input stream, then it is attached to some input source for the process, such as standard input (the keyboard) or a socket into which data flows from the Internet. If the stream is an output stream, then it is attached to some output source for the process, such as standard output (the monitor) or a socket out of which data flows into the Internet.

Client-socket, welcoming socket, and connection socket


client program, server program, network application, socket programming, stream, tcp

Copy Right

The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.