Networking Basics Computers running on the Internet communicate to each other using either the Transmission Control Protocol

(TCP) or the User Datagram Protocol (UDP), as this diagram illustrates:

When you write Java programs that communicate over the network, you are programming at the application layer. Typically, you don't need to concern yourself with the TCP and UDP layers. Instead, you can use the classes in the java.net package. These classes provide systemindependent network communication. However, to decide which Java classes your programs should use, you do need to understand how TCP and UDP differ. TCP When two applications want to communicate to each other reliably, they establish a connection and send data back and forth over that connection. This is analogous to making a telephone call. If you want to speak to Aunt Beatrice in Kentucky, a connection is established when you dial her phone number and she answers. You send data back and forth over the connection by speaking to one another over the phone lines. Like the phone company, TCP guarantees that data sent from one end of the connection actually gets to the other end and in the same order it was sent. Otherwise, an error is reported. TCP provides a point-to-point channel for applications that require reliable communications. The Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), and Telnet are all examples of applications that require a reliable communication channel. The order in which the data is sent and received over the network is critical to the success of these applications. When HTTP is used to read from a URL, the data must be received in the order in which it was sent. Otherwise, you end up with a jumbled HTML file, a corrupt zip file, or some other invalid information.

Definition: TCP (Transmission Control Protocol) is a connection-based protocol that provides a reliable flow of data between two computers.

UDP

The UDP protocol provides for communication that is not guaranteed between two applications on the network. UDP is not connection-based like TCP. Rather, it sends independent packets of data, called datagrams, from one application to another. Sending datagrams is much like sending a letter through the postal service: The order of delivery is not important and is not guaranteed, and each message is independent of any other.

Definition: UDP (User Datagram Protocol) is a protocol that sends independent packets of data, called datagrams, from one computer to another with no guarantees about arrival. UDP is not connection-based like TCP.

For many applications, the guarantee of reliability is critical to the success of the transfer of information from one end of the connection to the other. However, other forms of communication don't require such strict standards. In fact, they may be slowed down by the extra overhead or the reliable connection may invalidate the service altogether. Consider, for example, a clock server that sends the current time to its client when requested to do so. If the client misses a packet, it doesn't really make sense to resend it because the time will be incorrect when the client receives it on the second try. If the client makes two requests and receives packets from the server out of order, it doesn't really matter because the client can figure out that the packets are out of order and make another request. The reliability of TCP is unnecessary in this instance because it causes performance degradation and may hinder the usefulness of the service. Another example of a service that doesn't need the guarantee of a reliable channel is the ping command. The purpose of the ping command is to test the communication between two programs over the network. In fact, ping needs to know about dropped or out-of-order packets to determine how good or bad the connection is. A reliable channel would invalidate this service altogether. The UDP protocol provides for communication that is not guaranteed between two applications on the network. UDP is not connection-based like TCP. Rather, it sends independent packets of data from one application to another. Sending datagrams is much like sending a letter through the mail service: The order of delivery is not important and is not guaranteed, and each message is independent of any others.

Note: Many firewalls and routers have been configured not to allow UDP packets. If you're having trouble connecting to a service outside your firewall, or if clients are having trouble connecting to your service, ask your system administrator if UDP is permitted.

Understanding Ports

Generally speaking, a computer has a single physical connection to the network. All data destined for a particular computer arrives through that connection. However, the data may be intended for different applications running on the computer. So how does the computer know to which application to forward the data? Through the use of ports. Data transmitted over the Internet is accompanied by addressing information that identifies the computer and the port for which it is destined. The computer is identified by its 32-bit IP address, which IP uses to deliver data to the right computer on the network. Ports are identified by a 16-bit number, which TCP and UDP use to deliver the data to the right application. In connection-based communication such as TCP, a server application binds a socket to a specific port number. This has the effect of registering the server with the system to receive all data destined for that port. A client can then rendezvous with the server at the server's port, as illustrated here:

Definition: The TCP and UDP protocols use ports to map incoming data to a particular process running on a computer.

In datagram-based communication such as UDP, the datagram packet contains the port number of its destination and UDP routes the packet to the appropriate application, as illustrated in this figure:

Port numbers range from 0 to 65,535 because ports are represented by 16-bit numbers. The port numbers ranging from 0 - 1023 are restricted; they are reserved for use by well-known services such as HTTP and FTP and other system services. These ports are called well-known ports. Your applications should not attempt to bind to them. Networking Classes in the JDK Through the classes in java.net, Java programs can use TCP or UDP to communicate over the Internet. The URL, URLConnection, Socket, and ServerSocket classes all use TCP to

communicate over the network. The DatagramPacket, DatagramSocket, and MulticastSocket classes are for use with UDP. Java includes several classes for socket programming. The two classes that can be used are java.net.ServerSocket, which encapsulates a server socket, and java.net.Socket, which implements a client socket. The constructors and key methods of the two classes are shown in Tables 1 and 2, respectively. The sole constructor for a server socket, ServerSocket (int which binds the socket to the specified port [, int time]) port. Optionally, the amount of time to listen for a connection may be specified. Socket accept () void close () InetAddress getInetAddress () Returns a connection on a new socket Closes the connection. Returns the address to which the socket is connected. Returns the port to which the socket is connected. Returns a String showing the socket's address and port.

int getLocalPort ()

String toString ()

Table 1. java.net.ServerSocket class The constructor and key methods for the java.net.ServerSocket class. The constructor and accept and close methods throw an IOException if an I/O error occurs.

Constructor to create a socket, and connect it to the specified hostname and port. The socket will Socket (String be a stream socket if isStream is absent or is true, hostname, int port [, and a datagram socket otherwise. An boolean isStream]) UnknownHostException is thrown if the host is not found. Constructor to create a socket and connect it to Socket (InetAddress the specified IP address and port. The socket will address, int port [, be a stream socket if isStream is absent or is true, boolean isStream]) and a datagram socket otherwise. synchronized close () InetAddress getInetAddress () int getPort () InputStream getInputStream () OutputStream getOutputStream () void

Closes the socket.

Returns the address to which the socket is connected. Returns the port to which the socket is connected.

Returns an input stream for the socket.

Returns an output stream for the socket.

String toString ()

Returns a String showing the socket's address and port.

Table 2. java.net.Socket class The constructor and key methods for the java.net.Socket class. The second constructor and the close, getInputStream and getOutputStream methods throw an IOException if an I/O error occurs.

Table 3 lists the key methods for a useful class, java.net.InetAddress (it has no constructors), which may be used for encapsulating IP addresses. static synchronized Returns an InetAddress object for the given InetAddress getByName hostname, expressed in the usual format (String hostname) (e.g. machine.domain.com). static InetAddress Returns an InetAddress object for the local getLocalHost () host. static synchronized InetAddress Returns an array of all InetAddress objects getAllByName (String for the given hostname. hostname) String getHostName () Returns the host name for the InetAddress. Returns a String with the corresponding IP address for the InetAddress.

String toString ()

Table 3. java.net.InterAddress class The key methods for the java.net.InetAddress utility class. This class has no public constructor; the methods getByName(), getLocalHost() or getAllByName() must be used to instantiate an object. These three methods all throw UnknownHostException if the address is unknown. The server will sit and listen to the specified port, but it cannot actually do anything until a connection is made to it. Thus, the Accept call must be used to block execution of the program until a client makes a request. When that happens, the accept method terminates, returning a java.net.Socket object. This socket will be used in the same fashion as with any instance of java.net.Socket in a client, and will enable network communication. Hence, the ServerSocket's main purpose is to wait for a connection, and then pass it to another socket for processing. Following the invocation of the Accept method, a DataInputStream is constructed and associated with the new socket, its readLine method called, and the string that is returned is displayed on the screen. Finally, both sockets are closed&theprogramterminates.

Sockets:

The client begins by creating a Socket object. The local hostthe address being returned from a call to InetAddress.getLocalHost()but this is just for simplicity; the server could be run on any remote computer, in which case the client must get the address of the appropriate machine instead of calling for the local host. The port numbers must match between the client and the server or else they cannot communicate. The program then constructs a PrintStream associated with the socket, and its println method called to send a message to the server. The socket is then closed, and the program terminates. The flush method simply forces any buffered writes to complete. Although the simple scenario just described demonstrates client-server programming, it is not terribly useful in practice. For example, the client and the server do not have a great deal of interaction. Usually, the server will return information to the client (writing to the socket in the same way the client did). Further, the server socket above terminated after transmission of just one client message. Typically, we would expect the server to run continually, and process many client requests, terminating only when the computer is shut down. In fact, this last expectation is what makes servers more complicated than clients. Many clients may be run, either on the same machine in a multitasking environment, or on many different machines. However, there will always be only one server on a machine to process incoming requests. Hence, not only must the server continue to exist after it has processed requests, but it must deal with client requests concurrently. Java adapts to this situation easily, via threads. It is made possible using an enhanced multithreaded server program that is able to respond to many client requests simultaneously. This new server creates a new thread to process each incoming request. Hence, once the Accept method has returned a Socket object, a ServerThread is created and its start method is invoked. Further, the server continues to accept requests by looping. Although the internal design of the server has changed considerably, it still prints messages as before, and the very same client program is being used. The ServerThread contains a constructor that initializes some variables and a run() method. This run() method is required by any thread and is where you actually implement the code to be executed when your thread is set running. Think of it as the "main() method" for a thread, if you will. The run() method here is trivial; it simply displays the message read from the socket. Nevertheless, the code provides the beginning of what could become a very complex server, if the run() method were replaced with something more substantial.