Java provides two approaches for performing a task in a new thread: 1) defining a subclass of the Thread class with a run() method that performs the task, and instantiating it; or 2) defining a class that implements the Runnable interface with a run() method that performs the task, and passing an instance of that class to the Thread constructor. In either case, the new thread does not begin execution until its start() method is invoked. The first approach can only be used for classes that do not already extend some other class; therefore, we stick with the second approach, which is always applicable. The Runnable interface contains a single method prototype:

     interface Runnable {
       void run();
     }

When the start() method of an instance of Thread is invoked, the JVM causes the instance’s run() method to be executed in a new thread, concurrently with all others. Meanwhile, the original thread returns from its call to start() and continues its execution independently. (Note that directly calling run() does not create a new thread; instead, the run() method is simply executed in the caller’s thread, just like any other method call.) The statements of each thread’s run() method are interleaved in a nondeterministic fashion, so in general it is not possible to predict precisely the order in which things will happen in different threads.

In the following example, ThreadExample.java implements the Runnable interface with a run() method that repeatedly prints a greeting to the system output stream.

ThreadExample.java

 0  import java.util.concurrent.TimeUnit;
 1
 2  public class ThreadExample implements Runnable {
 3
 4    private String greeting; // Message to print to console

 5
 6    public ThreadExample(String greeting) {
 7      this.greeting = greeting;
 8    }
 9
10   public void run() {
11     while (true) {
12       System.out.println(Thread.currentThread().getName() + ":   " + greeting);
13       try {
14        // Sleep 0 to 100 milliseconds
15        TimeUnit.MILLISECONDS.sleep(((long) Math.random() * 100));
16       } catch (InterruptedException e) {
17       } // Should not happen
18     }
19   }
20
21   public static void main(String[] args) {
22     new Thread(new ThreadExample("Hello")).start();
23     new Thread(new ThreadExample("Aloha")).start();
24     new Thread(new ThreadExample("Ciao")).start();
25   }
26  }

ThreadExample.java

Upon execution, an interleaving of the three greeting messages is printed to the console. The exact interleaving of the numbers depends upon various factors that in general are not observable. Threads are perfect for implementing servers like our example, in which each client’s processing is independent of that provided to every other client. However, it is a different story when client processing involves updating information that is shared across threads on the server. In that case, great care must be taken to ensure that different threads are properly synchronized with respect to the shared data; otherwise, the shared information can get into an inconsistent state, and moreover, the problem can be very difficult to trace. A full treatment of techniques and facilities for concurrency would require a book of its own. The book by Goetz et al. [9], for example, is excellent.

Since the multitasking server approaches we are going to describe are independent of the particular client-server protocol, we want to be able to use the same protocol implementation for both. The code for the echo protocol is given in the class EchoProtocol. This class encapsulates the per-client processing in the static method handleEchoClient(). This code is almost identical to the connection-handling portion of TCPEchoServer.java, except that a logging capability (described shortly) has been added; the method takes references to the client Socket and the Logger instance as arguments.

The class implements Runnable (the run() method simply invokes handle EchoClient() with the instance’s Socket and Logger references), so we can create a thread that independently executes run(). Alternatively, the server-side protocol processing can be invoked by calling the static method directly (passing it the Socket and Logger references).

EchoProtocol.java

 0  import java.io.IOException;
 1  import java.io.InputStream;
 2  import java.io.OutputStream;
 3  import java.net.Socket;
 4  import java.util.logging.Level;
 5  import java.util.logging.Logger;
 6
 7  public class EchoProtocol implements Runnable {
 8    private static final int BUFSIZE = 32; // Size (in bytes) of I/O buffer

 9    private Socket clntSock;               // Socket connect to client
10    private Logger logger;                 // Server logger
11
12    public EchoProtocol(Socket clntSock, Logger logger) {
13      this.clntSock = clntSock;
14      this.logger = logger;
15    }
16
17    public static void handleEchoClient(Socket clntSock, Logger logger) {
18      try {
19        // Get the input and output I/O streams from socket
20        InputStream in = clntSock.getInputStream();
21        OutputStream out = clntSock.getOutputStream();
22
23        int recvMsgSize; // Size of received message
24        int totalBytesEchoed = 0; // Bytes received from client
25        byte[] echoBuffer = new byte[BUFSIZE]; // Receive Buffer
26        // Receive until client closes connection, indicated by -1
27        while ((recvMsgSize = in.read(echoBuffer)) != -1) {
28           out.write(echoBuffer, 0, recvMsgSize);
29           totalBytesEchoed += recvMsgSize;
30        }
31
32        logger.info("Client " + clntSock.getRemoteSocketAddress() + ", echoed "
33             + totalBytesEchoed + " bytes.");
34
35      } catch (IOException ex) {
36        logger.log(Level.WARNING, "Exception in echo protocol", ex);
37      } finally {
38        try {
39          clntSock.close();
40        } catch (IOException e) {
41        }
42      }
43    }
44
45    public void run() {
46      handleEchoClient(clntSock, logger);
47    }
48  }

EchoProtocol.java

Your server is up and running with thousands of clients per minute. Now a user reports a problem. How do you determine what happened? Is the problem at your server? Perhaps the client is violating the protocol. To deal with this scenario, most servers log their activities. This practice is so common that Java now includes built-in logging facilities in the java.util.logging package. We provide a very basic introduction to logging here; however, be aware that there are many more features to enterprise-level logging.

We begin with the Logger class, which represents a logging facility that may be local or remote. Through an instance of this class, we can record the various server activities as shown in EchoProtocol. You may use several loggers in your server, each serving a different purpose and potentially behaving in a different way. For example, you may have separate loggers for operations, security, and error messages. In Java each logger is identified by a globally unique name. To get an instance of Logger, call the static factory method Logger.getLogger() as follows:

     Logger logger = Logger.getLogger("practical");

This fetches the logger named “practical”. If a logger by that name does not exist, a new logger is created; otherwise, the existing logger instance is returned. No matter how many times you get the “practical” logger in your program, the same instance is returned.

Now that you have logging, what should you log? Well, it depends on what you are doing. If the server is operating normally, you may not want to log every single step the server takes because logging consumes resources such as space for storing log entries and server processor time for writing each entry. On the other hand, if you are trying to debug, you may want to log each and every step. To deal with this, logging typically includes the notion of the level, or severity, of log entries. The Level class encapsulates the notion of the importance of messages. Each instance of Logger has a current level, and each message logged has an associated level; messages with levels below the instance’s current level are discarded (i.e., not logged). Each level has an associated integer value, so that levels are comparable and can be ordered. Seven system-recognized instances of Level are defined; other, user-specific, levels can be created, but there is rarely any need to do so. The built-in levels (defined as static fields of the class Level) are: SEVERE, WARNING, INFO, CONFIG, FINE, FINER, and FINEST.

So when you log, where do the messages go? The logger sends messages to one or more Handlers, which “handle” publishing the messages. By default, a logger has a single ConsoleHandler that prints messages to System.err. You can change the handler or add additional handlers to a logger (e.g., FileHandler). Note that like a logger, a handler has a minimum log level, so for a message to be published its level must be above both the logger and handlers’ threshold. Loggers and handlers are highly configurable, including their minimum level.

An important characteristic of Logger for our purposes is that it is thread-safe —that is, its methods can be called from different threads running concurrently without requiring additional synchronization among the callers. Without this feature, different messages logged by different threads might end up being interleaved in the log!

static Logger getLogger(String name)
static Logger getLogger(String name, String resourceBundleName)

Once we have the logger, we need to ... well ... log. Logger provides fine-grained logging facilities that differentiate between the level and even context (method call, exception, etc.) of the message.

void severe(String msg)
void warning(String msg)
void info(String msg)
void config(String msg)
void fine(String msg)
void finer(String msg)
void finest(String msg)

void entering(String sourceClass, String sourceMethod)
void entering(String sourceClass, String sourceMethod, Object param)
void entering(String sourceClass, String sourceMethod, Object[] params)
void exiting(String sourceClass, String sourceMethod)
void exiting(String sourceClass, String sourceMethod, Object result)
void throwing(String sourceClass, String sourceMethod, Throwable thrown)

void log(Level level, String msg)
void log(Level level, String msg, Throwable thrown)

We may want to customize our logger by setting the minimum logging level or the handlers for logging messages.

Handler[] getHandlers()
void addHandler(Handler handler)
void removeHandler(Handler handler)

Level getLevel()
void setLevel(Level newLevel)
boolean isLoggable(Level level)

We are now ready to introduce some different approaches to concurrent servers.

In a thread-per-client server, a new thread is created to handle each connection. The server executes a loop that runs forever, listening for connections on a specified port and repeatedly accepting an incoming connection from a client and then spawning a new thread to handle that connection.

TCPEchoServerThread.java implements the thread-per-client architecture. It is very similar to the iterative server, using a single loop to receive and process client requests. The main difference is that it creates a thread to handle the connection instead of handling it directly. (This is possible because EchoProtocol implements the Runnable interface.) Thus, when several clients connect at approximately the same time, later ones do not have to wait for the server to finish with the earlier ones before they get service. Instead, they all appear to receive service (albeit at a somewhat slower rate) at the same time.

TCPEchoServerThread.java

 0  import java.io.IOException;
 1  import java.net.ServerSocket;
 2  import java.net.Socket;
 3  import java.util.logging.Logger;
 4
 5  public class TCPEchoServerThread {
 6
 7    public static void main(String[] args) throws IOException {
 8
 9      if (args.length != 1) { // Test for correct # of args
10       throw new IllegalArgumentException("Parameter(s): <Port>");
11     }
12
13     int echoServPort = Integer.parseInt(args[0]); // Server port
14
15     // Create a server socket to accept client connection requests
16     ServerSocket servSock = new ServerSocket(echoServPort);
17
18     Logger logger = Logger.getLogger("practical");
19
20     // Run forever, accepting and spawning a thread for each connection
21     while (true) {
22       Socket clntSock = servSock.accept(); // Block waiting for connection
23       // Spawn thread to handle new connection
24       Thread thread = new Thread(new EchoProtocol(clntSock, logger));
25       thread.start();
26       logger.info("Created and started Thread " + thread.getName());
27     }
28     /* NOT REACHED */
29   }
30  }

TCPEchoServerThread.java

Every new thread consumes system resources: spawning a thread takes CPU cycles and each thread has its own data structures (e.g., stacks) that consume system memory. In addition, when one thread blocks, the JVM saves its state, selects another thread to run, and restores the state of the chosen thread in what is called a context switch. As the number of threads increases, more and more system resources are consumed by thread overhead. Eventually, the system is spending more time dealing with context switching and thread management than with servicing connections. At that point, adding an additional thread may actually increase client service time.

We can avoid this problem by limiting the total number of threads and reusing threads. Instead of spawning a new thread for each connection, the server creates a thread pool on start-up by spawning a fixed number of threads. When a new client connection arrives at the server, it is assigned to a thread from the pool. When the thread finishes with the client, it returns to the pool, ready to handle another request. Connection requests that arrive when all threads in the pool are busy are queued to be serviced by the next available thread.

Like the thread-per-client server, a thread-pool server begins by creating a ServerSocket. Then it spawns N threads, each of which loops forever, accepting connections from the (shared) ServerSocket instance. When multiple threads simultaneously call accept() on the same Server-Socket instance, they all block until a connection is established. Then the system selects one thread, and the Socket instance for the new connection is returned only in that thread. The other threads remain blocked until the next connection is established and another lucky winner is chosen.

Since each thread in the pool loops forever, processing connections one by one, a thread-pool server is really like a set of iterative servers. Unlike the thread-per-client server, a thread-pool thread does not terminate when it finishes with a client. Instead, it starts over again, blocking on accept(). An example of the thread-pool paradigm is shown in TCPEchoServerPool.java.

TCPEchoServerPool.java

 0  import java.io.IOException;
 1  import java.net.ServerSocket;
 2  import java.net.Socket;
 3  import java.util.logging.Level;
 4  import java.util.logging.Logger;
 5

 6  public class TCPEchoServerPool {
 7
 8    public static void main(String[] args) throws IOException {
 9
10      if (args.length != 2) { // Test for correct # of args
11        throw new IllegalArgumentException("Parameter(s): <Port> <Threads>");
12      }
13
14      int echoServPort = Integer.parseInt(args[0]); // Server port
15      int threadPoolSize = Integer.parseInt(args[1]);
16
17      // Create a server socket to accept client connection requests
18      final ServerSocket servSock = new ServerSocket(echoServPort);
19
20      final Logger logger = Logger.getLogger("practical");
21
22      // Spawn a fixed number of threads to service clients
23      for (int i = 0; i <  threadPoolSize; i++) {
24        Thread thread = new Thread() {
25          public void run() {
26            while (true) {
27              try {
28                Socket clntSock = servSock.accept(); // Wait for a connection
29                EchoProtocol.handleEchoClient(clntSock, logger); // Handle it
30              } catch (IOException ex) {
31                logger.log(Level.WARNING, "Client accept failed", ex);
32              }
33            }
34          }
35        };
36        thread.start();
37        logger.info("Created and started Thread = " +  thread.getName());
38      }
39    }
40  }

TCPEchoServerPool.java

Since threads are reused, the thread-pool solution only pays the overhead of thread creation N times, irrespective of the total number of client connections. Since we control the maximum number of simultaneously executing threads, we can control scheduling and resource overhead. Of course, if we spawn too few threads, we can still have clients waiting a long time for service; therefore, the size of the thread pool needs to be tuned to the load, so that client connection time is minimized. The ideal would be a dispatching facility that expands the thread pool (up to a limit) when the load increases, and shrinks it to minimize overhead during times when the load is light. It turns out that Java has just such a facility; we describe it in the next section.

In the previous subsections, we have seen that encapsulating the details of the client-server protocol (as in EchoProtocol.java) lets us use different “dispatching” methods with the same protocol implementation (e.g., TCPEchoServerThread.java and TCPEchoServerThreadPool.java). In fact the same thing is true for the dispatching methods themselves. The interface Executor (part of the java.util.concurrent package) represents an object that executes Runnable instances according to some strategy, which may include details about queueing and scheduling, or how jobs are selected for execution. The Executor interface specifies a single method:

    interface Executor {
      void execute(Runnable task);
    }

Java provides a number of built-in implementations of Executor that are convenient and simple to use, and others that are extensively configurable. Some of these offer handling for messy details like thread maintenance. For example, if a thread stops because of an uncaught exception or other failure, they automatically spawn a new thread to replace it.

The ExecutorService interface extends Executor to provide a more sophisticated facility that allows a service to be shut down, either gracefully or abruptly. ExecutorService also allows for tasks to return a result, through the Callable interface, which is like Runnable, only with a return value.

Instances of ExecutorService can be obtained by calling various static factory methods of the convenience class Executors. The program TCPEchoServerExecutor.java illustrates the use of the basic Executor facilities.

TCPEchoServerExecutor.java

 0  import java.io.IOException;
 1  import java.net.ServerSocket;
 2  import java.net.Socket;
 3  import java.util.concurrent.Executor;
 4  import java.util.concurrent.Executors;
 5  import java.util.logging.Logger;
 6
 7  public class TCPEchoServerExecutor {
 8
 9    public static void main(String[] args) throws IOException {
10
11      if (args.length != 1) { // Test for correct # of args
12        throw new IllegalArgumentException("Parameter(s): <Port>");
13      }
14
15      int echoServPort = Integer.parseInt(args[0]); // Server port
16
17      // Create a server socket to accept client connection requests
18      ServerSocket servSock = new ServerSocket(echoServPort);
19
20      Logger logger = Logger.getLogger("practical");
21
22      Executor service = Executors.newCachedThreadPool();  // Dispatch svc
23
24      // Run forever, accepting and spawning a thread for each connection
25      while (true) {
26        Socket clntSock = servSock.accept(); // Block waiting for connection
27        service.execute(new EchoProtocol(clntSock, logger));
28      }
29      /* NOT REACHED */
30    }
31  }

TCPEchoServerExecutor.java

Once we have a server designed to use Executor for dispatching clients, we can change dispatching strategies simply by changing the kind of Executor we instantiate. For example, if we wanted to use a fixed-size thread pool as in our TCPEchoServerPool.java example, it is a matter of changing one line associated with setting the dispatch service:

    Executor service = Executors.newFixedThreadPool(threadPoolSize);

We could switch to a single thread to execute all connections either by specifying a pool size of 1, or by the following call:

    Executor service = Executors.newSingleThreadExecutor();

In the Executor approach, if the single “worker” thread dies because of some failure, the Executor will replace it with a new thread. Also, tasks are queued inside the Executor, instead of being queued inside the networking system, as they were in our original server. Note that we’ve only scratched the surface of Java’s concurrency package.

For these methods, we can set a bound on the maximum time (in milliseconds) to block, using the setSoTimeout() method of Socket, ServerSocket, and DatagramSocket. If the specified time elapses before the method returns, an InterruptedIOException is thrown. For Socket instances, we can also use the available() method of the socket’s InputStream to check for available data before calling read().

The Socket constructor attempts to establish a connection to the host and port supplied as arguments, blocking until either the connection is established or a system-imposed timeout occurs. Unfortunately, the system-imposed timeout is long, and Java does not provide any means of shortening it. To fix this, call the parameterless constructor for Socket, which returns an unconnected instance. To establish a connection, call the connect() method on the newly constructed socket and specify both a remote endpoint and timeout (milliseconds).

A write() call blocks until the last byte written is copied into the TCP implementation’s local buffer; if the available buffer space is smaller than the size of the write, some data must be successfully transferred to the other end of the connection before the call to write() will return (see Section 6.1 for details). Thus, the amount of time that a write() may block is ultimately controlled by the receiving application. Unfortunately, Java currently does not provide any way to cause a write() to time out, nor can it be interrupted by another thread. Therefore, any protocol that sends a large enough amount of data over a Socket instance can block for an unbounded amount of time. (See Section 6.2 for a discussion of the potentially disastrous consequences of this.)

Suppose we want to implement the Echo protocol with a limit on the amount of time taken to service each client. That is, we define a target, TIMELIMIT, and implement the protocol in such a way that after TIMELIMIT milliseconds, the protocol instance is terminated. The protocol instance keeps track of the amount of time remaining, and uses setSoTimeout() to ensure that no read() call blocks for longer than that time. Since there is no way to bound the duration of a write() call, we cannot really guarantee that the time limit will hold. Nevertheless, Time-limitEchoProtocol.java implements this approach; to use it with TCPEchoServerExecutor.java, simply change the second line of the body of the while loop to:

    service.execute(new TimeLimitEchoProtocol(clntSock, logger));

Again, Chapter 5 will cover more powerful mechanisms that can limit the time that threads can block—on all I/O calls, including writes—using the facilities of the NIO package.

TimeLimitEchoProtocol.java

 0  import java.io.IOException;
 1  import java.io.InputStream;
 2  import java.io.OutputStream;
 3  import java.net.Socket;
 4  import java.util.logging.Level;
 5  import java.util.logging.Logger;
 6
 7  class TimelimitEchoProtocol implements Runnable {
 8    private static final int BUFSIZE = 32;  // Size (bytes) of buffer
 9    private static final String TIMELIMIT = "10000";   // Default limit (ms)
10    private static final String TIMELIMITPROP = "Timelimit";   // Property
11
12    private static int timelimit;
13    private Socket clntSock;
14    private Logger logger;
15
16    public TimelimitEchoProtocol(Socket clntSock, Logger logger) {
17      this.clntSock = clntSock;
18      this.logger = logger;
19      // Get the time limit from the System properties or take the default
20      timelimit = Integer.parseInt(System.getProperty(TIMELIMITPROP,TIMELIMIT));
21    }
22
23    public static void handleEchoClient(Socket clntSock, Logger logger) {
24
25      try {
26        // Get the input and output I/O streams from socket
27        InputStream in = clntSock.getInputStream();
28        OutputStream out = clntSock.getOutputStream();
29        int recvMsgSize;                        // Size of received message
30        int totalBytesEchoed = 0;               // Bytes received from client
31        byte[] echoBuffer = new byte[BUFSIZE];  // Receive buffer
32        long endTime = System.currentTimeMillis() + timelimit;
33        int timeBoundMillis = timelimit;

34
35         clntSock.setSoTimeout(timeBoundMillis);
36         // Receive until client closes connection, indicated by -1
37         while ((timeBoundMillis > 0) &&      // catch zero values
38                ((recvMsgSize = in.read(echoBuffer)) != -1)) {
39           out.write(echoBuffer, 0, recvMsgSize);
40           totalBytesEchoed += recvMsgSize;
41           timeBoundMillis = (int) (endTime - System.currentTimeMillis()) ;
42           clntSock.setSoTimeout(timeBoundMillis);
43         }
44         logger.info("Client " + clntSock.getRemoteSocketAddress() +
45                     ", echoed " + totalBytesEchoed + " bytes.");
46       } catch (IOException ex) {
47         logger.log(Level.WARNING, "Exception in echo protocol", ex);
48       }
49     }
50
51     public void run() {
52       handleEchoClient(this.clntSock, this.logger);
53     }
54  }

TimeLimitEchoProtocol.java

The TimelimitEchoProtocol class is similar to the EchoProtocol class, except that it attempts to bound the total time an echo connection can exist to 10 seconds. At the time the handleEchoClient() method is invoked, a deadline is computed using the current time and the time bound. After each read(), the time between the current time and the deadline is computed, and the socket timeout is set to the remaining time.

Broadcasting UDP datagrams is similar to unicasting datagrams, except that a broadcast address is used instead of a regular (unicast) IP address. Note that IPv6 does not explicitly provide broadcast addresses; however, there is a special all-nodes, link-local-scope multicast address, FFO2::1, that multicasts to all nodes on a link. The IPv4 local broadcast address (255.255.255.255) sends the message to every host on the same broadcast network. Local broadcast messages are never forwarded by routers. A host on an Ethernet network can send a message to all other hosts on that same Ethernet, but the message will not be forwarded by a router. IPv4 also specifies directed broadcast addresses, which allow broadcasts to all hosts on a specified network; however, since most Internet routers do not forward directed broadcasts, we do not deal with them here.

There is no networkwide broadcast address that can be used to send a message to all hosts. To see why, consider the impact of a broadcast to every host on the Internet. Sending a single datagram would result in a very, very large number of packet duplications by the routers, and bandwidth would be consumed on each and every network. The consequences of misuse (malicious or accidental) are too great, so the designers of IP left such an Internetwide broadcast facility out on purpose.

Even so, local broadcast can be very useful. Often, it is used in state exchange for network games where the players are all on the same local (broadcast) network. In Java, the code for unicasting and broadcasting is the same. To play with broadcasting applications, we can simply use our VoteClientUDP.java with a broadcast destination address. There is one problem. Can you find it? Hint: You cannot use connect with broadcast. Run VoteServerUDP.java as you did before (except that you can run several receivers at one time). Caveat: Some operating systems do not give regular users permission to broadcast, in which case this will not work.

As with broadcast, one of the main differences between multicast and unicast is the form of the address. A multicast address identifies a set of receivers. The designers of IP allocated a range of the address space dedicated to multicast, specifically 224.0.0.0 to 239.255.255.255 for IPv4 and any address starting with FF for IPv6. With the exception of a few reserved multicast addresses, a sender can send datagrams addressed to any address in this range. In Java, multicast applications generally communicate using an instance of MulticastSocket, a subclass of DatagramSocket. It is important to understand that a MulticastSocket is actually a UDP socket (DatagramSocket), with some extra multicast-specific attributes that can be controlled. Our next examples implement a multicast sender and receiver of vote messages.

VoteMulticastSender.java

 0  import java.io.IOException;
 1  import java.net.DatagramPacket;
 2  import java.net.InetAddress;
 3  import java.net.MulticastSocket;
 4
 5  public class VoteMulticastSender {
 6
 7    public static final int CANDIDATEID = 475;
 8
 9    public static void main(String args[]) throws IOException {
10
11      if ((args.length < 2) || (args.length > 3)) { // Test # of args
12        throw new IllegalArgumentException("Parameter(s): <Multicast Addr> <Port> [<TTL>]");
13      }
14
15      InetAddress destAddr = InetAddress.getByName(args[0]); // Destination
16      if (!destAddr.isMulticastAddress()) { // Test if multicast address
17        throw new IllegalArgumentException("Not a multicast address");
18      }
19
20      int destPort = Integer.parseInt(args[1]); // Destination port
21      int TTL = (args.length == 3) ? Integer.parseInt(args[2]) : 1; // Set TTL
22
23      MulticastSocket sock = new MulticastSocket();
24      sock.setTimeToLive(TTL); // Set TTL for all datagrams
25
26      VoteMsgCoder coder = new VoteMsgTextCoder();
27
28      VoteMsg vote = new VoteMsg(true, true, CANDIDATEID, 1000001L);
29
30      // Create and send a datagram
31      byte[] msg = coder.toWire(vote);
32      DatagramPacket message = new DatagramPacket(msg, msg.length, destAddr, destPort);
33      System.out.println("Sending Text-Encoded Request (" + msg.length + " bytes): ");

34      System.out.println(vote);
35      sock.send(message);
36
37      sock.close();
38    }
39  }

VoteMulticastSender.java

The only significant differences between our unicast and multicast senders are that 1) we verify that the given address is multicast, and 2) we set the initial Time To Live (TTL) value for the multicast datagram. Every IP datagram contains a TTL, initialized to some default value and decremented (usually by one) by each router that forwards the packet. When the TTL reaches zero, the packet is discarded. By setting the initial value of the TTL, we limit the distance a packet can travel from the sender.^[1]

Unlike broadcast, network multicast duplicates the message only to a specific set of receivers. This set of receivers, called a multicast group, is identified by a shared multicast (or group) address. Receivers need some mechanism to notify the network of their interest in receiving data sent to a particular multicast address, so that the network can forward packets to them. This notification, called joining a group, is accomplished with the joinGroup() method of MulticastSocket. Our multicast receiver joins a specified group, receives and prints a single multicast message from that group, and exits.

VoteMulticastReceiver.java

 0  import java.io.IOException;
 1  import java.net.DatagramPacket;
 2  import java.net.InetAddress;
 3  import java.net.MulticastSocket;
 4  import java.util.Arrays;
 5
 6  public class VoteMulticastReceiver {
 7
 8    public static void main(String[] args) throws IOException {
 9
10     if (args.length != 2) { // Test for correct # of args
11       throw new IllegalArgumentException("Parameter(s): <Multicast Addr> <Port>");
12     }
13
14     InetAddress address = InetAddress.getByName(args[0]); // Multicast address

15     if (!address.isMulticastAddress()) { // Test if multicast address
16       throw new IllegalArgumentException("Not a multicast address");
17     }
18
19     int port = Integer.parseInt(args[1]); // Multicast port
20     MulticastSocket sock = new MulticastSocket(port); // for receiving
21     sock.joinGroup(address); // Join the multicast group
22
23     VoteMsgTextCoder coder = new VoteMsgTextCoder();
24
25     // Receive a datagram
26     DatagramPacket packet = new DatagramPacket(new byte[VoteMsgTextCoder.MAX_WIRE_LENGTH],
27         VoteMsgTextCoder.MAX_WIRE_LENGTH);
28     sock.receive(packet);
29
30     VoteMsg vote = coder.fromWire(Arrays.copyOfRange(packet.getData(), 0, packet
31        .getLength()));
32
33     System.out.println("Received Text-Encoded Request (" + packet.getLength()
34         + " bytes): ");
35     System.out.println(vote);
36
37     sock.close();
38    }
39  }

VoteMulticastReceiver.java

The only significant difference between our multicast and unicast receiver is that the multicast receiver must join the multicast group by supplying the desired multicast address. The book’s Web site also contains another example of a sender and receiver multicast pair. MulticastImageSender.java transmits a set of images (JPEG or GIF) specified on the command line, in three-second intervals. MulticastImageReceiver.java receives each image and displays it in a window.

Multicast datagrams can, in fact, be sent from a DatagramSocket by simply using a multicast address. However, a MulticastSocket has a few capabilities that a DatagramSocket does not, including 1) allowing specification of the datagram TTL, and 2) allowing the interface through which datagrams are sent to the group to be specified/changed (an interface is identified by its Internet address). A multicast receiver, on the other hand, must use a MulticastSocket because it needs the ability to join a group.

MulticastSocket is a subclass of DatagramSocket, so it provides all of the DatagramSocket methods. We only present methods specific to or adapted for MulticastSocket.

MulticastSocket()
MulticastSocket(int localPort)
MulticastSocket(SocketAddress bindaddr)

If we wish to receive any datagrams, we need to join a multicast group.

void joinGroup(InetAddress groupAddress)
void joinGroup(SocketAddress mcastaddr, NetworkInterface netIf)
void leaveGroup(InetAddress groupAddress)
void leaveGroup(SocketAddress mcastaddr,  NetworkInterface netIf)

int getTimeToLive()
void setTimeToLive(int ttl)
boolean getLoopbackMode()
void setLoopbackMode(boolean disable)
InetAddress getInterface()
NetworkInterface getNetworkInterface()
void setInterface(InetAddress inf)
void setNetworkInterface(NetworkInterface netIf)

The decision to use broadcast or multicast depends on several factors, including the network location of receivers and the knowledge of the communicating parties. The scope of a broadcast on the Internet is restricted to a local broadcast network, placing severe restrictions on the location of the broadcast receivers. Multicast communication may include receivers anywhere in the network,^[2] so multicast has the advantage that it can cover a distributed set of receivers. The disadvantage of IP multicast is that receivers must know the address of a multicast group to join. Knowledge of an address is not required to receive broadcast. In some contexts, this makes broadcast a better mechanism than multicast for discovery. All hosts can receive broadcast by default, so it is simple to ask all hosts on a single network a question like “Where’s the printer?”

UDP unicast, multicast, and broadcast are all implemented using an underlying UDP socket. The semantics of most implementations are such that a UDP datagram will be delivered to all sockets bound to the destination port of the packet. That is, a DatagramSocket or Multi-castSocket instance bound to a local port X (with local address not specified, i.e., a wild card), on a host with address Y will receive any UDP datagram destined for port X that is 1) unicast with destination address Y, 2) multicast to a group that any application on Y has joined, or 3) broadcast where it can reach host Y. A receiver can use connect() to limit the datagram source address and port. Also, a DatagramSocket can specify the local unicast address, which prevents delivery of multicast and broadcast packets. See UDPEchoClientTimeout.java for an example of destination address verification and Section 6.5 for details on datagram demultiplexing.

If no data has been exchanged for a while, each endpoint may be wondering if the other is still around. TCP provides a keep-alive mechanism where, after a certain time of inactivity, a probe message is sent to the other endpoint. If the endpoint is alive and well, it sends an acknowledgment. After a few retries without acknowledgment, the probe sender gives up and closes the socket, eliciting an exception on the next attempted I/O operation. Note that the application only sees keep-alive working if the probes fail.

boolean getKeepAlive()
void setKeepAlive(boolean on)

When a Socket or DatagramSocket is created, the operating system must allocate buffers to hold incoming and outgoing data. (We talk about this in much greater detail in Section 6.1.)

int getReceiveBufferSize()
void setReceiveBufferSize(int size)
int getSendBufferSize()
void setSendBufferSize(int size)

You can also specify the receive buffer size on a ServerSocket; however, this actually sets the receive buffer size for new Socket instances created by accept(). Why can you only set the receive buffer size and not the send buffer? When you accept a new Socket, it can immediately begin receiving data so you need the receive buffer size set before accept() completes the connection. On the other hand, you control when you send on a newly accepted socket, which gives you time to set the send buffer size before sending.

int getReceiveBufferSize()
void setReceiveBufferSize(int size)

As we’ve already seen, many I/O operations will block if they cannot complete immediately: reads block until at least 1 byte is available and accept blocks until a connection is initiated. Unfortunately, the blocking time is not bounded. We can specify a maximum blocking time for the various operations.

int getSoTimeout()
void setSoTimeout(int timeout)

Under some circumstances, you may want to allow multiple sockets to bind to the same socket address. In the case of UDP multicast, you may have multiple applications on the same host participating in the same multicast group. For TCP, when a connection is closed, one (or both) endpoints must hang around for a while in “Time-Wait” state to vacuum up stray packets (see Section 6.4.2). Unfortunately, you may not be able to wait for the Time-Wait to expire. In both cases, you need the ability to bind to an address that’s in use. To enable this, you must allow address reuse.

boolean getReuseAddress()
void setReuseAddress(boolean on)

TCP attempts to help you avoid sending small packets, which waste network resources. It does this by buffering data until it has more to send. While this is good for the network, your application may not be so tolerant of this buffering delay. Fortunately, you can disable this behavior.

boolean getTcpNoDelay()
void setTcpNoDelay(boolean on)

Suppose you’ve sent a bunch of data to a slow receiver and suddenly you have some data that the receiver needs right now. If you send the data in the output stream, it gets queued up behind all of the regular data, and who knows when the receiver will see it? To deal with this TCP includes the concept of urgent data that can (theoretically) skip ahead. Such data is called out-of-band because it bypasses the normal stream.

void sendUrgentData(int data
boolean getOOBInline()
void setOOBInline(boolean on)

Note that Java can get little use from urgent data because urgent bytes are mixed in with regular bytes in the order of transmission. In fact, a Java receiver cannot even tell that it’s receiving urgent data.

When you call close() on a socket, it immediately returns even if the socket is buffering unsent data. The problem is that your host could then fail at a later time without sending all of the data. You may optionally ask close() to “linger,” or block, by blocking until all of the data is sent and acked or a timeout expires. See Section 6.4.2 for more details.

int getSoLinger()
void setSoLinger(boolean on, int linger)

Some operating systems require that you explicitly request permission to broadcast. You can control broadcast permissions. As you already know, DatagramSockets provide broadcast service.

boolean getBroadcast()
void setBroadcast(boolean on)

Some networks offer enhanced or “premium” services to packets classified as being eligible for the service. The traffic class of a packet is indicated by a value carried in the packet as it is transmitted through the network. For example, some networks might give packets in the “gold service” class higher priority, to provide reduced delay and/or reduced loss probability. Others might use the indicated traffic class to choose a route for the packet. Beware, however, that network providers charge extra for such services, so there is no guarantee these options will actually have any effect.

int getTrafficClass()
void setTrafficClass(int tc)

TCP may not be the only protocol available to a socket. Which protocol to use depends on what’s important to your application. Java allows you to give “advice” to the implementation regarding the importance of different performance characteristics to your application. The underlying network system may use the advice to choose among different protocols that can provide equivalent stream services with different performance characteristics.

void setPerformancePreferences(int connectionTime, int latency, int bandwidth)