Sockets and the ‘Talk’ Applications in C and Java

I. IntroductionAs examples of sockets and how they can be used at the transport level, two

similar applications have been developed, one in C and one in Java, that allow two computers to be used as terminals at which one user uses a terminal to communicate with the user at the other terminal. Effectively, these are primitive chat programs. They serve as useful examples for ELE437 because they are complete applications by themselves, are simple enough to understand without having to be very familiar with the language they are written in due to detailed commenting (although it is assumed that the student is more familiar with Java than C), and most importantly they make use of sockets.

This paper will cover what sockets are, what their capabilities are in terms of network communications, how they are used in the example applications, and what issues involving error-handling and transport-level communications need to be considered. It is intended to assist students taking ELE437 who have little or no understanding of what sockets are and how they may be used. For that reason, references to specific sections and page numbers in the ELE437 text book written by Tanenbaum will be made in italics following descriptions of some subjects.

II. What Are Sockets?Sockets are endpoints for network communications, connection-oriented or

connectionless, commonly used at the transport level. Each end-point may be addressed using a “port number”, which is a 16-bit number (from 1 to 65535, while 0 is often used to mean “any available port”) that is a part of the network address. For example, most web pages have a port number of 80. Since this is the default port number used by web servers, and the default port number expected by browsers supporting the HTTP protocol, the addresses http://www.google.com and http://www.google.com:80 are equivalent. If a web server uses a different port number than 80 however, the port number must be used explicitly using the format:

http://domain_name:port_numberwhere “port_number” is the port number of the end-point you wish to communicate with.

To clarify what an “endpoint” really is, the general steps involved in transferring data from a network adapter to a software application are described in the remainder of this paragraph. When a data packet arrives on a network adapter, the adapter will in turn cause a hardware interrupt that will allow the packet to be transferred into the system’s memory. Next, software interrupts most likely controlled by the operating system will determine the executing application bound to the address and port specified in the packet’s header. A particular thread within the application expecting this data will then be informed (by the operating system) that the payload of the packet is available for pickup at a particular endpoint it has access to. The application then uses function calls to access this endpoint in order to retrieve the data and process it in any way it wishes.

Programming languages and operating system API’s (Application Program Interfaces) often provide several services for sockets including those that create a socket (SOCKET), bind the socket to a particular network resource based on an address and port number (BIND), and connect (CONNECT) and disconnect (CLOSE) to and from another

socket that is either local or remote. A more complete list of the services typically available is in Table 1: Berkeley Socket Primitives which is located below.

Please refer to pages 487-488 (Section 6.1.3) in the text for Tanenbaum’s general description of sockets. For other information on sockets, the web page addresses in the references section at the end of this paper may be of assistance.

Table 1: Berkeley Socket PrimitivesTCP UDP Description

Server

socket() socket() Creates a socket as an end-pointbind() bind() Binds a socket to a local addresslisten() Listens for connection requestsaccept() Listens for and accepts connection requestsread()write()recv()send()

recvfrom()sendto() Transfers data to and from a client

Client

socket() socket() Creates a socket as an end-pointbind() bind() Binds a socket to a local address

connect() Connects to a server accepting connectionsread()write()recv()send()

sendto()recvfrom() Transfers data to and from a server

Termination close() or shutdown() close() TCP: Disconnects and closes the socket

UDP: Closes the socket

Section III. Understanding SocketsHow sockets work and can be used to carry out communications must be

described in a bit more detail before proceeding. Examples using code similar to the ‘Talk’ applications will be used for demonstration. Please note that some portions of the original C code may be skipped for simplicity. Also, some portions of the original Java code may be modified for better out-of-context presentation or expanded in order to both make it more comparable to the C code and to show where all of the primitives are being called upon rather than letting Socket constructors hide many of these details.

The best way to understand the use of sockets is by examples. This section provides examples of the creation, use, and destruction sockets as sets of discrete steps. There are generally two kinds of sockets, those used by a server to accept connections, and those used by a client to request a connection. Each kind will be presented separately in step-by-step form here

Five steps involved in the use of a Server Socket are given on the following pages, including descriptions of each step and source code examples in C and Java.

Server Step 1: Creation of a Server SocketThe socket itself must be created as something that can be accessed in a program.

In some languages, each socket must also have certain properties defined for it in order to be created. These properties may include the data transfer method used (blocks/messages or byte stream) and a particular protocol at the transport layer to use. C requires these properties to properly create a socket, whereas Java offers the ability to automatically use byte streams and the TCP/IP protocol when sockets are to be used over a connection. Byte streams and TCP/IP are used for both the server and client sockets in these examples and therefore the Talk applications as well.

In terms of what is returned by a socket when it is created, each language uses a slightly different approach. C returns an integer representing a file descriptor (a descriptor referring to a file or other resource that may be treated as a file, such as a socket) when a call to the socket() function is made, while Java returns a pointer to a Socket object when one of the Socket constructors is called. Once created, socket primitives or functions that call upon the primitives may be used to set up and use the socket, as later steps will show. Please note that in order to simply the distinction between a socket that will act as a server and one that will act as a client, Java includes a ServerSocket class for servers and a Socket class for clients. No equivalent distinction is made in C, however this is ideal for learning many of the lower-level details involved in creating and using sockets for different uses.

C: Creation of a Server Socket /* File descriptor for the server socket - “socketfd” will contain an integer representing a file descriptor,

which will allow the programmer to treat the socket the descriptor is related to as if it were simply a file */

int socketfd;/* Socket address for the server - Used to store the network address, address type, and a port number

for the server’s socket/* struct sockaddr_in server;

/* A call to SOCKET is made here that creates an IPv4 stream socket. - The file descriptor for the socket “socketfd” is returned - “socketfd” has no address, port, or ability to accept connections

at this point because only its basic properties are defined.- The AF_INET property means that the socket will use Internet

addresses in the Internet Protocol version 4 (IPv4) format - The SOCK_STREAM property means that the socket will use a byte

stream for communication over the socket as opposed to messages */socketfd = socket(AF_INET, SOCK_STREAM, 0);

Java: Creation of a Server Socket/* Creates a stream socket for use with an Internet address. It

includes methods such as accept() that allow it to act as a server once an address and port have been bound to it (see Step 2 on the next page) */

ServerSocket server = new ServerSocket();

Server Step 2: Binding a Server SocketThe next step is to assign an address and port number to the socket. This may be

done by binding it to a local network adapter. This means that a local address and port must be selected. Most servers are expected to be operating on the same address and port all of the time, in which case the socket may be bound to these and unless the binding process fails the clients will know where to send their connection requests. In some cases however, it is desirable to use a wildcard value for the address so that the server will accept connections on any network interface in the current machine. This can be done using “INADDR_ANY” as the address in C and by not defining a binding address in Java. Similarly, the port number can be defined as 0, meaning that any available port is acceptable. Be especially careful with random port numbers however, because your clients will still need to know the port number in order to connect to your server.

Please refer to pages 493-496 (Section 6.2.1) in the text for other information about ports and addressing that is related to binding (or “attaching” as Tanenbaum sometimes calls it).

C: Binding a Server Socket/* The “sin_family” field in the server’s address holds a value

representing the address type. In this case, it is an Internetaddress (AF_INET) in IPv4 form */

server.sin_family = AF_INET;

/* The “sin_addr.s_addr” field in the server’s address holds an Internet host address. In this case, it holds INADDR_ANYwhich means that a connection arriving on any address of anylocal network adapter will be responded to. */

server.sin_addr.s_addr = INADDR_ANY;

/* The “sin_port” field in the server’s address holds the number of the port bound to the socket. In this case, 0 was specified.Selecting 0 will cause a random, valid, available port to be assigned to the “sin_port” field when a call to bind() is made */

server.sin_port = 0;

/* Binds the server’s socket to all of the local network adapters on a random, valid, available (unused) port number in order to prepare the socket for the ability to listen for and accept connections made from remote clients */

bind(socketfd, (struct sockaddr*)&server, sizeof(server));

Java: Binding a Server Socket (Expanded)//Any unused local portint localPort = 0;

//Create an address representing any/all local network adapter // addresses and a single random, valid, unused port numberSocketAddress address = new InetSocketAddress(localPort)

//Bind the server’s socket to the local adapters and random port// as specified in the instance of “SocketAddress” named “address”server.bind(address);

Server Step 3: Accepting a Connection Request The server may now wait for a connection request to arrive on the local port and

local address(es) it is bound to. This may be done by using the ACCEPT primitive which “blocks” until such a request arrives from a client. Making a call to a “blocking” function means that the program will appear to freeze as the point were that function was called until a condition being monitored at a lower level (in hardware or software) releases the block. In a case where a call to accept() is made, the return from the function is blocked until a connection request arrives, at which point the application will resume execution normally until the next blocking call is made.

It should be obvious that blocking can be very inefficient, especially for server applications that are based on a single thread of execution but must provide services to multiple users “simultaneously.” In those cases, using function calls that time out if they block for specified maximum time period would allow program execution to resume, thus creating the illusion that the application is capable of simultaneously waiting for connections and handling the ones that have already been established.

In cases where the server application can be written to use multiple threads, the same kind of illusion is created, but from the view of the programmer and the machine each thread is a small program that must take turns executing along side the other threads. A significant advantage to using multiple threads rather than a single one when blocking calls must be made is that if one thread makes a blocking function call, none of the other threads will be affected. This will generally result in improved performance and less complex applications that are easier to write and maintain.

As yet another alternative, sometimes functions are available that are non-blocking or allow you to check if another function will block if you call it. These can be useful in both single and multi-threaded applications, but will not be discussed further here.

C: Accepting a Connection Request/* File descriptor that corresponds to the socket over which the

communication with the client will take place) */int msgsock;

/* Accept a new connection to our server’s socket when a connection request arrives on any local network adapter for the port number that was assigned to the server’s address in the call to bind() in Step 2 */msgsock = accept(socketfd, (struct sockaddr*)0, (int*)0);

Java: Accepting a Connection Request//Socket over which the communication with the client will take placeSocket socket;

/* Accept a new connection to our server’s socket when a connection request arrives on any local network adapter for the port number that was assigned to the server’s address in the call to bind() in Step 2 */socket = server.accept();

Server Step 4: Sending and Receiving Data over a ConnectionOnce a connection has been established, users on both sides of the connection are

able to send and receive data to and from one another. The connections established in the previous steps will allow data to be transferred as byte streams, as opposed to transferring messages (blocks of data) or packets which are more commonly used for connectionless communications.

Whereas the sockets used in both C and Java for the previous steps provided functions corresponding to the socket primitives involved, Java makes a significant departure when it comes to sending and receiving data. C will use the recv() and send() primitives, however Java’s sockets require you to access the socket’s input stream (using getInputStream() ) in order to receive and its output stream (using getOutputStream() ) in order to send data. These methods return objects of type InputStream and OutputStream respectively, however these streams cannot be used directly. Instead, input and output streams with complete (non-abstract) implementations must be created using the InputStream and OutputStream objects returned.

In the example below, DataInputStream and DataOutputStream objects are constructed using the socket’s streams. These may be used to transmit bytes (byte, byte[]), integers (short, int, long), floating point values (float, double), characters (char, char[]), Boolean values (boolean), and character strings (String). This is obviously far more powerful and useful for a programmer than simply being able to transfer bytes or byte arrays using the send() and recv() primitives, but it is important to realize that all of the additional data types mentioned are still converted to and from individual bytes at the sending and receiving ends of the connection between two sockets.

C: Receiving and Sending Data/* Create a 1024-character buffer for temporary message storage */char buffer[1024];

/* Receive data on the server’s socket (“socketfd”) and store it in the character buffer named “buffer” */

recv(socketfd, buffer, 1, 0);

/* Insert code that uses the received data here */

/* Send data stored in the character buffer out on the server socket */send(socketfd, buffer, rval, 0);

Java: Receiving and Sending Data//Bind input & output data streams to the socket connected to a clientinput = new DataInputStream (socket.getInputStream() );output = new DataOutputStream (socket.getOutputStream() );

//Receive a line of text on the socket as a character stringString receivedText = input.readLine();

// Insert code that uses the received data here

//Send a line of text out over the socketoutput.writeChars(“This is a string of characters”);

Server Step 5: Closing the Server SocketWhen the client is done communicating with the server, or the server must be shut

down for any reason, the connection between the client and server must be broken. In order for the connection to be broken properly, the application running at each side should make a call to a close() function that corresponds to the close() socket primitive.

If the server’s design requires that it accept another connection after the one previously established is terminated, then the lines of code that makes calls to accept() may be placed in a loop followed by any program code that will use the socket as well as a call to close().

If this was a one-time connection, the server’s job is complete and the socket may be closed down, however no loop is used accept() more connections.

In either case, the CLOSE primitive is designed to break the connection established in Step 3 gracefully (without generating any errors, and with both sides of the connection acknowledging explicitly or implicitly that the disconnection has taken place). This will also release resources in memory related to the socket and free up the port number it was bound to.

C: Closing the Server Socket (Accepting More Connections)/* Loop until the server application is terminated in order to accept a

connection from a client after another client has completed its session with the server */

while (1){/* Accept a new connection to our server’s socket when a connection request arrives on any local network adapter for the port number that was assigned to the server’s address in the call to bind() in Step 2 */ msgsock = accept(socketfd, (struct sockaddr*)0, (int*)0);

/* If the file descriptor value for the socket is not a negative number, then a valid descriptor for the socket was returned by the call to accept() and the socket may now be used to communicate with a connected client */

if (msgsock >= 0){ /* Insert code that uses the socket here */

/* Disconnect from the client and close the socket */ close(msgsock); }}

Java: Closing the Server Socket (One-time Connection)//Socket over which the communication with the client will take placeSocket socket;

/* Accept a new connection to our server’s socket when a connection request arrives on any local network adapter for the port number that was assigned to the server’s address in the call to bind() in Step 2 */socket = server.accept();

// Insert code that uses the socket here

// Disconnect from the client and close the socketsocket.close();// Close the server socket, not accepting any more connectionsserver.close();

The steps involved in the use of a client socket are somewhat different than those for server sockets. In Step 2 (Binding) the client almost never cares what local address and port their socket is bound to. Recall that servers usually want to have a specific address and port number so that they may be easily identified. Also, in Step 3 the client will be sending a connection request whereas a server listens for and accepts connection requests. Steps 1 (socket creation), 4 (sending and receiving data), and 5 (closing the socket) are similar, but not identical to those steps for a server and will therefore not include as much as detail as the previous section on server sockets.

Client Step 1: Creation of a Client Socket The socket itself must be created as something that can be accessed in a program.

C uses an integer representing a file descriptor to refer to sockets, while Java uses a pointer to a socket object. Once created, socket primitives may be used to set up and use the socket, as later steps will show.

C: Creation of a Client Socket/* File descriptor for the client socket */int socketfd;

/* Call to SOCKET is made here. It returns a socket file descriptor *//* Create Internet Protocol Version 4 (IPv4) stream socket.

Function: socket(int domain, int socketType, int protocol)Location: sys/socket.h

Parameters: domain = AF_INET = Internet domainsocketType = SOCK_STREAM = Byte-stream socketprotocol = 0 = Default protocol for SOCK_STREAM

*/socketfd = socket(AF_INET, SOCK_STREAM, 0);

Java: Creation of a Client Socket/* Creates a stream socket for use with an Internet address. It

includes methods that allow it to establish a connection to server sockets that are listening for connection attempts */

Socket socket = new Socket();

Client Step 2: Binding a Client SocketThe socket must be bound to a local network adapter. This is quite similar to

Server Step 2, however the port number your socket binds to is typically insignificant because you don’t need to tell the server which port to connect to. Also, the local network adapter address that the socket is bound to shouldn’t be important as long as the adapter is connected to a network that can communicate with the server the client wishes to connect to.

Please note that the C example provided here makes an implicit call to bind() when the connect() function is called. This is done because customizing the parameters used for a bind operation is so much more relevant for a server than it is for a client it is suitable to allow the client socket to bind to any address an port that permit it to send a connection request to a particular server.

Please refer to pages 493-496 (Section 6.2.1) in the text for other information about ports and addressing that is related to binding (or “attaching” as Tanenbaum sometimes calls it).

C: Binding a Client Socket/* Address of the remote server that the client plans to establish a

connection to */struct sockaddr_in server;/* Host Entity (name and IP address) of the server the client is

planning on establishing a connection to */struct hostent *hp;

/* The “sin_family” field in the server’s address holds a value representing the address type. In this case, it is an Internetaddress (AF_INET) in IPv4 form */

server.sin_family = AF_INET;

/* Get information about the server based on a character string named “hostname” that was specified by the user as the server’s host name */hp = gethostbyname(hostname);

/* Copy information about the remote server from “hp” into the socket address named “server” for use with the connect() function */

memcpy((char*)&server.sin_addr, (char*)hp->h_addr, hp->h_length);

/* “sin_port” in sockaddr_in holds a port as a short integer *//* atol(string) = ASCII to Long; Converts a string to a long integer *//* htons(short) in netinet/in.h converts an address in

host byte order to network byte order (big endian)*/server.sin_port = htons((int)atol(portstr));

/* Call to BIND and CONNECT is made below. The call to BIND isdone within the function for CONNECT and chooses a randomavailable port on the local system to bind the socket to. After the binding takes place, an attempt to establish a connection the server is made. */

/* Initiate connection on a socket Function: connect( int socket_fd, struct sockaddr *address, socklen_t address_len ) Location: sys/socket.h Parameters: socket_fd = socketfd = Socket file descriptor address = server = the server sockaddr_in struct address_len = sizeof(server) = the socket's size in bytes */connect(socketfd, (struct sockaddr*)&server, sizeof(server));

Java: Binding a Client SocketString localAddr = null; //any local network adapterint localPort = 0; //any available local port number

SocketAddress address = new InetSocketAddress(localAddr, localPort);socket.bind(address);

Client Step 3: Connecting a Client to a ServerThe client may now send a connection request to a server using the CONNECT

primitive. This involves sending a connection request, receiving an acknowledgement with information about how to complete the connection, and finally the completion of the connection.

Please refer to pages 496-502 (Section 6.2.2) of the text for many more details on the steps involved in establishing connections, as well as some of the complications involved that are made transparent to the programmer.

C: Connecting a Client to a ServerSee “C: Binding a Client Socket” for Client Step 2 (on the previous page)

Java: Connecting a Client to a Server//Local IPv4 address of a URI computer (as a character string)String servAddr = “131.128.51.97”;//Default server port number for the Talk application in Javaint servPort = 5574;

//Attempt to establish a connection to servAddr:servPortSocketAddress address = new InetSocketAddress(servAddr, servPort);socket.connect(address);

Client Step 4: Sending and Receiving Data over a ConnectionPlease refer to Server Step 4 because the usage of sockets once a connection has

been established is the same once a connection has been established.

Client Step 5: Closing a Client SocketWhen the client is done communicating with the server, or the server must be shut

down for any reason, the connection between the client and server must be broken. In order for the connection established in Step 3 to be broken properly (without generating any errors, and with both sides of the connection acknowledging explicitly or implicitly that the disconnection has taken place), the application running at each side should make a call to a close() function that corresponds to the close() socket primitive. In addition to breaking the connection, close() will release resources in memory related to the socket and free up the port number it was bound to.

Please refer to pages 502-506 (Section 6.2.3) of the text for many more details on the steps involved in properly releasing connections, as well as some of the complications involved that are made transparent to the programmer.

C: Closing a Client Socketclose(socketfd);

Java: Closing a Client Socketsocket.close();

Section IV. Alternate Code Examples in JavaAlternate versions of some of the Java examples provided in the previous section are

given below. A more complete demonstration of the underlying behavior of these examples in terms of the socket primitives involved, as presented in Section III, was necessary before these examples could be given and understood fully.

Create and Bind a Server Socket to any Local Network Adapter on the Specified Portint serverPortNumber = 5574;ServerSocket server = new ServerSocket(serverPortNumber);

Create a Client Socket, Bind it to Any Local Address and Port, and Connect to the Specified Server Address and Port

String serverAddress = “131.128.51.97”;int serverPort = 5574;Socket socket = new Socket(serverAddress, serverPort);

Create a Client Socket, Bind it to the Specified Local Address and Port, and Connect to the Specified Server Address and Port

String serverAddr = “131.128.51.97”;int serverPort = 5574;InetAddress localAddr = InetAddress.getLocalHost();int localPort = 0; //use any available local portSocket socket = new Socket(serverAddr, serverPort, localAddr, localPort);

V. The ‘Talk’ ApplicationsTwo applications have been written as examples of how sockets may be used.

One is in C and it has been tested on UNIX-based systems. The other is in Java and may be run on Windows, Linux, and Solaris. Both are designed to allow the users of two different computers using TCP/IP on a network to “talk” with one another from a terminal interface.

Since either user should be capable of acting as the server or the client, both applications are capable of starting up in either of these modes. The examples of how servers and clients connect and disconnect given in Section III: Understanding Sockets already demonstrated how several of the steps involved in the Talk applications are carried out. For that reason, and because the full source code is available for those who wish to see it, only a step-by-step description will be given about how Talk operates. Differences in the operation of the C and Java versions will be pointed out when necessary.

Outline of Steps Taken by a ‘Talk’ Server1. Start the program as a Server in Java or as a Daemon in C2. A socket is created, bound to any local network adapter with an IP address, and

waits to accept a connection request from a remote client3. A connection request arrives causing a connection to be established between the

server and client machines

4. The user at the server and client can type text to one anothera. In the C version, the characters corresponding to the keys pressed are sent

immediately over the connection and appear on the remote terminalb. In the Java version, the characters are sent on a line-by-line basis because

the ability to read input from the keyboard is blocked until an End Of Line (EOL) is detected meaning that Enter/Return was pressed.

5. When the users are done chatting, they may close the connection and exit Talka. In the C version, the connection may be terminated by pressing CTRL-C

or CTRL-Db. In the Java version, the connection may be terminated by pressing CTRL-

C or by typing the word “exit” as a message and pressing Enter/Return.

Outline of Steps Taken by a ‘Talk’ Client1. Start the program as a Client. This requires that the server’s address and port

number be provided as parameters.2. A socket is created, bound to any local network adapter with an IP address, and a

connection request is sent to the server.3. The server accepts the connection to the client.4. Identical to Server Step 45. Identical to Server Step 5

After the connection has been established, whether the application was started as a server or a client, the activity in the program converges to a function that handles talking over the established connection. This makes sense because once a server socket has been used to establish a connection, a socket is returned that is connected to the client and may be used the same way as a client socket that has established a connection to a server. The result is that shared behaviors on both ends of the connection become possible, which include reading input from the keyboard, transmitting input from the keyboard over the socket, reading input received on the socket, and displaying received input. Once the connection has been broken, the main “talking” function will return and the applications are free to diverge again to perform server and client-specific duties.

VI. Error-handling with Sockets in ‘Talk’Two versions of each Talk program were written, one of each with very little error

detection and handling, and one of each with an amount of error checking that is more comparable to that of real-world applications. While checking related to invalid user input or a missing settings file are included in the error checking, the kinds of errors that you need to be concerned with right now are primarily those related to sockets and the underlying communications taking place. The following paragraphs will describe many of the problems a programmer should take into consideration while using sockets in general, and more specifically when sockets are used in a connection-oriented environment. If you haven’t already done so, please refer to pages 496-502 (Section 6.2.2) of the text if you wish to read about more details on the steps and complications involved in establishing connections.

A socket may fail at just about any of the steps described in Section III. The problem can begin as early as when a socket it created, even though it isn’t bound or connected to anything. Creating a bare socket (unbound and unconnected) in a call to socket() in C will return a negative error code if the parameters specifying the socket’s basic properties (socket type, transmission method, and protocol) are invalid or not available on the system it is running on. In Talk, the socket is created as an Internet stream socket that will use any appropriate, available protocol. The error code is returned if the underlying operating system is incapable of creating an Internet stream socket or no support for an appropriate protocol is installed. In Java, a socket to be used for connections is automatically an Internet stream socket and the ability to create such a socket is guaranteed by the Java Virtual Machine running on top to the operating system. For that reason, no exceptions are thrown when a bare socket is created in Java.

In the case of binding, a request to bind to a non-existent or unavailable network device, address, or port will leave a socket unable to be used for networking. This will be reported in the form of an error. Such an error can be detected upon a call to bind() in C when a –1 is returned by the function and in Java when an IOException is thrown by the method. In C, a custom message providing more information about the error must be added by the programmer if they wish to inform the user about what has gone wrong. In Java, the error message in IOException.getMessage() that provides more information about the type of failure that occurred may be displayed by itself or in addition to a custom message in order to report an error to the user.

If binding succeeds, consider what happens when a client attempts to connect to a server using the server’s host name as the address, and that the host name cannot be resolved to an actual address (an IP address in Talk) by DNS servers. In this case, the lookup of the address will fail and can be detected in C when a call to gethostbyname() returns 0 and in Java when a call to InetAddress.getByName() throws an UnknownHostException. In Talk, such a failure is considered fatal and the application will close after reporting an error.

A connection attempt may fail for several other reasons including, but not limited to: A buffer overflow at the server that has caused the request to be lost A buffer overflow at the client that caused the request to never be sent A transmission failure at the physical layer that wasn’t recognized and corrected

by the network or data link layer The server has denied the connection request The server isn’t currently running The server is using a different address and/or port number than usual A timeout caused by the lack of a response from the server for any reason.

For the sake of simplicity, all cases other than the failure to resolve a host name may be grouped together, as is done in the Talk applications. The action taken is to report an error and exit the application, however more robust applications would almost definitely attempt to automatically re-establish a connection that was unexpectedly lost, have alternate methods of looking up the server’s current address and port if it has changed, and attempt to connect to a server more than once before giving up.

In the preferred case that the binding and connecting processes have been carried out successfully, then data transfer errors may be considered. Although rare, these can be especially complicated to deal with because while a connection at the transport layer

provides a virtually error-free communication channel, data corrupted during transmission can be perceived as valid if its checksums are all valid for the data present, and data corrupted in low-level software or hardware at the sender before the checksums were calculated and transmitted may also permit invalid data to be passed successfully between peers operating at the transport layer.

In order to handle these rare, but potentially disastrous failures, the data received may be checked for reasonability if it is of a known or detectable type that has a limited range of valid values for the particular application. In the event that it is not possible or appropriate to perform checking for reasonability, the application should be designed to transmit data over the connection in a message or packet-based format that numbers each unit of data transmitted and includes additional error detection (and possibly error correction) information so that data that must be retransmitted may be reduced to relatively small, easily identifiable segments. Of course, there can be a considerable amount of overhead involved in such an approach, so it is up to the application designer to decide how likely (or unlikely) they consider these types of errors to be and how important it is that their data be accurate exactly 100% of the time. Fortunately, in the design of Talk it is perfectly acceptable for every billionth of even millionth character sent to be incorrect because the mistake could easily be attributed to a far more frequently occurring typing error. For that reason, no additional error checking is performed on the transmitted and received data.

Another problem that may crop up while a connection is active is that the connection can be lost without the intervention of the application users. Anything such as failed routers, modems, phone lines, cable lines, network cables, satellite uplinks, or even a local network policy that limits the duration of or any other characteristic of the current connection may be the culprit when a connection ceases to exist unexpectedly. In most cases, the programmer will not know the exact condition that has caused the disconnection, which means that a generic reaction to a disconnection should be taken. Examples of such reactions include:

1. Do nothing in response (too easy and not a good idea)2. Display an error and possibly exit the application if it depends on the connection

being present in order to function3. Attempt to re-establish the connection by sending out one or more connection

requests automatically if the remote host was operating as a server4. Start a server on a known port number so that the disconnected remote host can

request a connection to in order re-establish the connection, regardless of whether the local host was acting as the server originally or not

5. A combination of reactions 3 and 4 in which both disconnected hosts run servers and send out connection requests in order to attempt to re-establish the connection in a rather urgent manner. In the event that two connections manage to be established as a result of the overlapping requests, the extra one may be kept as a backup or discarded depending on the needs of the application.

Since Talk is meant to be a simple example of how sockets may be used, it displays an error message and exits the application.

Finally, when a socket is to be closed normally in order to terminate a connection, a failure may still occur. Any of the reasons mentioned that an active connection might fail are capable of preventing steps involved in correctly breaking down the connection when

a call to close() is made. In C, the failure can be detected if close() returns a –1. In Java, it can be detected if a IOException and/or a SocketException are thrown by a call to close(). In any case, the failure to properly close a socket and any connection that may be present on it often means that the socket was partially closed already (if the connection had been lost) and that resources such as the port number the socket was using have already been released back into the system for use by other application.

ConclusionOverall, you should now be generally comfortable with what sockets are and what

they can be used for based on the primitives (services) they provide. I don’t expect anyone to be able to write any particularly elaborate networking applications based on the information in this paper alone, especially if it is only read through once. It should however be possible to use this as a guide on how to create simple networking applications, including ones such as Talk. By using this paper in conjunction with the source code for the Talk applications, information in the text book (including an example of an “Internet File Server” written in C and described on pages 488-492), and the resources on the web listed on the next page, it should be possible to create many other simple yet interesting applications such as:

A message server that allows users to submit messages to a server for other users who will receive them immediately if they are connected to the server, or will receive them the next time they connect to the server if they are disconnected when the messages first arrive

A system that allows clients to send text to a server and have properties of the text returned (character frequency, word frequency, word count, etc)

A trivia system that allows all of the clients connected to a server to provide zero or one answer per question in a limited period of time. The clients should not be allowed to view the responses sent to the server by any other clients to prevent cheating. The server will offer fractional amounts of points if more than client answers a given question correctly before time runs out, with the client who responded correctly first receiving the most points. If no correct answers are received then the question will be placed back in a pool of unused questions.

There are probably much better ideas, so don’t hesitate to use your imagination if you choose to write your own networking applications in the future. If you never intend to write a networking application, that is fine too as long as you learned a little bit about sockets and communication at the transport layer.

Related Materials in the fourth edition of “Computer Networks” by Tanenbaum

Section 6.1: “The Transport Service” (p481-492) 6.1.1-2: Describes the Transport Layer by itself and relative to other network layers 6.1.3: Introduces Berkeley Sockets 6.1.4: Provides as example of a file server using Berkeley Sockets that is written in C

Section 6.2: Elements of Transport Protocols (p492-510) 6.2.1: Describes addressing and the use of ports as endpoints bound to sockets 6.2.2: Describes the process of establishing a connection 6.2.3: Describes the process of releasing a connection 6.2.4: Brings attention to the need to buffering communications at the Transport level

Section 6.5: The Internet Transport Protocols: TCP (p532-553) Information on the protocol, packet format, connection management, and more

Additional Information for understanding the “Talk” program written in C

“Berkeley UNIX® System Calls and Interprocess Communication” Includes details on sockets, connections, file descriptors, blocking and much

more. Example code in C is provided in many sections and subsections of the paper

http://www-users.cs.umn.edu/~bentlema/unix/syscalls_and_ipc.html

“UNIX Seventh Edition Manual” Detailed manual for the UNIX operating system, including information on sockets

http://cm.bell-labs.com/7thEdMan/

Additional Information for understanding the “Talk” program written in Java

Official Java Tutorial by Sun: “All About Sockets” Includes a description of sockets in general and as they are used in Java. Provides some useful examples, including another simple client-server application

http://java.sun.com/docs/books/tutorial/networking/sockets/

Unofficial Java Tutorial by JavaWorld: “Sockets Programming in Java: A Tutorial” Covers many of the same topics of the “Berkeley UNIX System Calls” while

excluding both advanced topics and topics that aren’t related to Java. Useful if you only plan on using sockets in Java, however the guide is a bit dated

(1996) and additional capabilities have been added to sockets in Java since that time.http://www.javaworld.com/javaworld/jw-12-1996/jw-12-sockets.html

More Information On Berkeley Sockets

http://www.cs.binghamton.edu/~nael/classes/cs528/berkeleysockets.pdf

Information on TCP Internet Servers

http://www.cs.rutgers.edu/~iftode/intel.ppt