11.1.1 Clients and Servers

When writing network applications, it's common to talk about clients and servers. The distinction is increasingly vague, but the side that initiates the conversation is usually the client. The side that accepts the request to talk is usually the server. In the case where there are two peer applications using sockets to talk, the distinction is less important, but for simplicity we'll use the above definition.

For our purposes, the most important difference between a client and a server is that a client can create a socket to initiate a conversation with a server application at any time, while a server must prepare to listen for incoming conversations in advance. The java.net.Socket class represents a single side of a socket connection on either the client or server. In addition, the server uses the java.net.ServerSocket class to wait for connections from clients. An application acting as a server creates a ServerSocket object and waits, blocked in a call to its accept() method, until a connection arrives. When it does, the accept() method creates a Socket object the server uses to communicate with the client. A server carries on multiple conversations at once; there is only a single ServerSocket, but one active Socket object for each client, as shown in Figure 11.2.

Figure 11.2: Clients and servers, Sockets and ServerSockets

A client needs two pieces of information to locate and connect to another server on the Internet: a hostname (used to find the host's network address) and a port number. The port number is an identifier that differentiates between multiple clients or servers on the same host. A server application listens on a prearranged port while waiting for connections. Clients select the port number assigned to the service they want to access. If you think of the host computers as hotels and the applications as guests, then the ports are like the guests' room numbers. For one guest to call another, he or she must know the other party's hotel name and room number.

try { 
    Socket sock = new Socket("wupost.wustl.edu", 25); 
}  
catch ( UnknownHostException e ) { 
    System.out.println("Can't find host."); 
}  
catch ( IOException e ) { 
    System.out.println("Error connecting to host."); 
} 

Socket sock = new Socket("128.252.120.1", 25);    // wupost.wustl.edu 

try { 
    Socket server = new Socket("foo.bar.com", 1234); 
    InputStream in = server.getInputStream(); 
    OutputStream out = server.getOutputStream(); 
 
    // Write a byte 
    out.write(42); 
 
    // Write a newline or carriage return delimited string
    PrintWriter pout = new PrintWriter( out, true ); 
    pout.println("Hello!"); 
 
    // Read a byte 
    Byte back = in.read(); 
 
    // Read a newline or carriage return delimited string 
    BufferedReader bin = new BufferedReader( new InputStreamReader( in );
    String response = bin.readLine(); 
 
    // Send a serialized Java object
    ObjectOutputStream oout = new ObjectOutputStream( out );
    oout.writeObject( new java.util.Date() );
    oout.flush();

    server.close(); 
}  
catch (IOException e ) { } 

// Meanwhile, on foo.bar.com... 
try { 
    ServerSocket listener = new ServerSocket( 1234 ); 
 
    while ( !finished ) { 
        Socket client = listener.accept();    // wait for connection 
 
        InputStream in = client.getInputStream(); 
        OutputStream out = client.getOutputStream(); 
 
        // Read a byte 
        Byte someByte = in.read(); 
 
        // Read a newline or carriage return delimited string 
        BufferedReader bin = new BufferedReader( new InputStreamReader( in );
        String someString = bin.readLine(); 
 
        // Write a byte 
        out.write(43); 
 
        // Say goodbye
        PrintWriter pout = new PrintWriter( out, true ); 
        pout.println("Goodbye!"); 

        // Read a serialized Java object
        ObjectInputStream oin = new ObjectInputStream( in );
        Date date = (Date)oin.readObject();
 
        client.close(); 
    } 
 
    listener.close(); 
} 
catch (IOException e ) { } 

11.1.2 The DateAtHost Client

Many networked workstations run a time service that dispenses their local clock time on a well-known port. This was a precursor of NTP, the more general Network Time Protocol. In the next example, DateAtHost, we'll make a specialized subclass of java.util.Date that fetches the time from a remote host instead of initializing itself from the local clock. (See Chapter 9 for a complete discussion of the Date class.)

DateAtHost connects to the time service (port 37) and reads four bytes representing the time on the remote host. These four bytes are interpreted as an integer representing the number of seconds since the turn of the century. DateAtHost converts this to Java's variant of the absolute time (milliseconds since January 1, 1970, a date that should be familiar to UNIX users) and then uses the remote host's time to initialize itself:

import java.net.Socket;
import java.io.*;

public class DateAtHost extends java.util.Date {
    static int timePort = 37;
    static final long offset = 2208988800L;   //  Seconds from century to 
                                              //   Jan 1, 1970 00:00 GMT

    public DateAtHost( String host ) throws IOException {
        this( host, timePort );
    }

    public DateAtHost( String host, int port ) throws IOException {
        Socket server = new Socket( host, port );
        DataInputStream din = new DataInputStream( server.getInputStream() );
        int time = din.readInt();
        server.close();
 
        setTime( (((1L << 32) + time) - offset) * 1000 );
    }
}

That's all there is to it. It's not very long, even with a few frills. We have supplied two possible constructors for DateAtHost. Normally we'll use the first, which simply takes the name of the remote host as an argument. The second, overloaded constructor specifies the hostname and the port number of the remote time service. (If the time service were running on a nonstandard port, we would use the second constructor to specify the alternate port number.) This second constructor does the work of making the connection and setting the time. The first constructor simply invokes the second (using the this() construct) with the default port as an argument. Supplying simplified constructors that invoke their siblings with default arguments is a common and useful technique.

The second constructor opens a socket to the specified port on the remote host. It creates a DataInputStream to wrap the input stream and then reads a 4-byte integer using the readInt() method. It's no coincidence that the bytes are in the right order. Java's DataInputStream and DataOutputStream classes work with the bytes of integer types in network byte order (most significant to least significant). The time protocol (and other standard network protocols that deal with binary data) also uses the network byte order, so we don't need to call any conversion routines. (Explicit data conversions would probably be necessary if we were using a nonstandard protocol, especially when talking to a non-Java client or server.) After reading the data, we're finished with the socket, so we close it, terminating the connection to the server. Finally, the constructor initializes the rest of the object by calling Date's setTime() method with the calculated time value.[3]

[3] The conversion first creates a long value, which is the unsigned equivalent of the integer time. It subtracts an offset to make the time relative to the epoch (January 1, 1970) rather than the century, and multiples by 1000 to convert to milliseconds.

The DateAtHost class can work with a time retrieved from a remote host almost as easily as Date is used with the time on the local host. The only additional overhead is that we have to deal with the possible IOException that can be thrown by the DateAtHost constructor:

try { 
    Date d = new DateAtHost( "sura.net" ); 
    System.out.println( "The time over there is: " + d ); 
    int hours = d.getHours(); 
    int minutes = d.getMinutes(); 
    ... 
}  
catch ( IOException e ) { } 

This example fetches the time at the host sura.net and prints its value. It then looks at some components of the time using the getHours() and getMinutes() methods of the Date class.

11.1.3 The TinyHttpd Server

Have you ever wanted your very own Web server? Well, you're in luck. In this section, we're going to build TinyHttpd, a minimal but functional HTTP daemon. TinyHttpd listens on a specified port and services simple HTTP "get file" requests. They look something like this:

GET /path/filename [optional stuff] 

Your Web browser sends one or more requests as lines for each document it retrieves. Upon reading a request, the server tries to open the specified file and send its contents. If that document contains references to images or other items to be displayed inline, the browser continues with additional GET requests. For best performance (especially in a time-slicing environment), TinyHttpd services each request in its own thread. Therefore, TinyHttpd can service several requests concurrently.

Over and above the limitations imposed by its simplicity, TinyHttpd suffers from the limitations imposed by the fickleness of filesystem access. It's important to remember that file pathnames are still architecture dependent--as is the concept of a filesystem to begin with. This example should work, as-is, on UNIX and DOS-like systems, but may require some customizations to account for differences on other platforms. It's possible to write more elaborate code that uses the environmental information provided by Java to tailor itself to the local system. (Chapter 10 gives some hints about how.)

WARNING: The next example will serve files from your host without protection. Don't try this at work.

Now, without further ado, here's TinyHttpd:

import java.net.*;
import java.io.*;
import java.util.*;

public class TinyHttpd { 
    public static void main( String argv[] ) throws IOException {
        ServerSocket ss = new ServerSocket( Integer.parseInt(argv[0]) );
        while ( true )
            new TinyHttpdConnection( ss.accept() ).start();
    }
}

class TinyHttpdConnection extends Thread {
    Socket client;
    TinyHttpdConnection ( Socket client ) throws SocketException {
        this.client = client;
        setPriority( NORM_PRIORITY - 1 );
    }

    public void run() {
        try {
            BufferedReader in = new BufferedReader( 
                new InputStreamReader(client.getInputStream(), "8859_1") );
            OutputStream out = client.getOutputStream();
            PrintWriter pout = new PrintWriter( 
                new OutputStreamWriter(out, "8859_1"), true );
            String request = in.readLine();
            System.out.println( "Request: "+request );

            StringTokenizer st = new StringTokenizer( request );
            if ( (st.countTokens() >= 2) && st.nextToken().equals("GET") ) {
                if ( (request = st.nextToken()).startsWith("/") )
                    request = request.substring( 1 );
                if ( request.endsWith("/") || request.equals("") )
                    request = request + "index.html";
                try {   
                    FileInputStream fis = new FileInputStream ( request );
                    byte [] data = new byte [ fis.available() ];
                    fis.read( data );
                    out.write( data );
                    out.flush();
                } catch ( FileNotFoundException e ) {
                    pout.println( "404 Object Not Found" ); }
            } else 
                pout.println( "400 Bad Request" );
            client.close();
        } catch ( IOException e ) {
            System.out.println( "I/O error " + e ); }
    }
}

Compile TinyHttpd and place it in your class path. Go to a directory with some interesting documents and start the daemon, specifying an unused port number as an argument. For example:

% java TinyHttpd 1234

You should now be able to use your Web browser to retrieve files from your host. You'll have to specify the nonstandard port number in the URL. For example, if your hostname is foo.bar.com, and you started the server as above, you could reference a file as in:

http://foo.bar.com:1234/welcome.html 

TinyHttpd looks for files relative to its current directory, so the pathnames you provide should be relative to that location. Retrieved some files? All righty then, let's take a closer look.

TinyHttpd is comprised of two classes. The public TinyHttpd class contains the main() method of our standalone application. It begins by creating a ServerSocket, attached to the specified port. It then loops, waiting for client connections and creating instances of the second class, a TinyHttpdConnection thread, to service each request. The while loop waits for the ServerSocket accept() method to return a new Socket for each client connection. The Socket is passed as an argument to construct the TinyHttpdConnection thread that handles it.

TinyHttpdConnection is a subclass of Thread. It lives long enough to process one client connection and then dies. TinyHttpdConnection's constructor does two things. After saving the Socket argument for its caller, it adjusts its priority. By lowering its priority to NORM_PRIORITY-1 (just below the default priority), we ensure that the threads servicing established connections won't block TinyHttpd's main thread from accepting new requests. (On a time-slicing system, this is less important.) After our object is constructed, its start() method is invoked to bring the run() method to life.

The body of TinyHttpdConnection's run() method is where all the magic happens. First, we fetch an OutputStream for talking back to our client. The second line reads the GET request from the InputStream into the variable req. This request is a single newline-terminated String that looks like the GET request we described earlier. For this we use a BufferedInputStream wrapped around an InputStreamReader. We'll say more about the InputStreamReader in a moment.

We then parse the contents of req to extract a filename. The next few lines are a brief exercise in string manipulation. We create a StringTokenizer and make sure there are at least two tokens. Using nextToken(), we take the first token and make sure it's the word GET. (If both conditions aren't met, we have an error.) Then we take the next token (which should be a filename), assign it to req, and check whether it begins with "/". If so, we use substring() to strip the first character, giving us a filename relative to the current directory. If it doesn't begin with "/", the filename is already relative to the current directory. Finally, we check to see if the requested filename looks like a directory name (i.e., ends in slash) or is empty. In these cases, we append the familiar default filename index.html.

Once we have the filename, we try to open the specified file and load its contents into a large byte array. If all goes well, we write the data out to the client on the OutputStream. If we can't parse the request or the file doesn't exist, we wrap our OutputStream with a PrintStream to make it easier to send a textual message. Then we return an appropriate HTTP error message. Finally, we close the socket and return from run(), removing our Thread.

import java.io.*; 
 
class TinyHttpdSecurityManager extends SecurityManager {  
 
    public void checkAccess(Thread g) { }; 
    public void checkListen(int port) { }; 
    public void checkLink(String lib) { }; 
    public void checkPropertyAccess(String key) { }; 
    public void checkAccept(String host, int port) { }; 
    public void checkWrite(FileDescriptor fd) { }; 
    public void checkRead(FileDescriptor fd) { }; 
 
    public void checkRead( String s ) {  
        if ( new File(s).isAbsolute() || (s.indexOf("..") != -1) ) 
            throw new SecurityException("Access to file : "+s+" denied."); 
    }  
}  

System.setSecurityManager( new TinyHttpdSecurityManager() ); 

catch ( SecurityException e ) 
    pout.println( "403 Forbidden" ); 

11.1.4 Socket Options

The Java sockets API is a simplified interface to the general socket mechanisms. In a C environment, where all of the gory details of the network are visible to you, a lot of complex and sometimes esoteric options can be set on sockets to govern the behavior of the underlying protocols. Java gives us access to a few of the important ones. We'll refer to them by their C names so that you can recognize them in other networking books.

11.1.5 Proxies and Firewalls

Many networks are behind firewalls that prevent applications from opening direct socket connections to the outside network. Instead, they provide a service called SOCKS (named for sockets) that serves as a proxy server for socket connections, giving the administrators more control over what connections are allowed.

Java has built-in support for SOCKS. All you have to do is set some system properties in your application (in an applet, this should be already taken care of for you since you wouldn't have authority to set properties). Here's a list of the properties that configure Java to use a proxy server:

http.proxySet

A boolean (true or false) indicating whether to use the proxy

http.proxyHost

The proxy server name

http.proxyPort

The proxy port number

You can set these properties on the command line using the Java interpreter's -D option or by calling the System.setProperty() method. The command below runs MyProgram using the proxy server at foo.bar.com on port 1234:

% java -Dhttp.proxySet=true -Dhttp.proxyServer=foo.bar.com 
     -Dhttp.proxyPort=1234 MyProgram 

In Java 1.0.2 the names didn't have the http. prefix. Java version 1.1 and later checks for the new names and then the old names. If the firewall does not allow any outside socket connections, your applet or application may still be able to communicate with the outside world by using HTTP to send and receive data. See Chapter 12 for an example of how to perform an HTTP POST from an applet.