Beyond the Basics - TCP/IP Sockets in Java Practical Guide for Programmers - page 76

both block until a connection has been established (see Section 5.4). Meanwhile, long round-
trip times, high error rate connections, and slow (or deceased) servers may cause connection
establishment to take a long time. In all of these cases, the method returns only after the request
has been satisfied. Of course, a blocking method call halts the execution of the application.
What about a program that has other tasks to perform while waiting for call com-
pletion (e.g., updating the “busy” cursor or responding to user requests)? These programs
may have no time to wait on a blocked method call. Or what about lost UDP datagrams? In
UDPEchoClientTimeout.java , the client sends a datagram to the server and then waits to receive
a response. If a datagram is not received before the timer expires, receive() unblocks to allow
the client to handle the datagram loss. Here we describe the general nonblocking approaches
(where they exist) for various I/O methods. ( Note: As this topic goes to press, additional non-
blocking I/O features have been proposed for version 1.4 of the JDK. Because these features
are still under development, we do not cover them here.)

4.2.1 accept() , read() , and receive()

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() .

4.2.2 Connecting and Writing

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 (on the order of minutes), and Java
does not provide any means of shortening it.
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 5.1 for details). Thus, the amount of time that a write() may block is 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 5.2 for further discussion on the consequences.)

4.2.3 Limiting Per-Client Time

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. One approach