Non-blocking Socket Programming

Socket programs in Java can be made to work in both blocking and non-blocking mode. In blocking socket mode, a system call event halts the execution until an appropriate reply has been received. In non-blocking sockets, it continues to execute even if the system call has been invoked and deals with its reply appropriately later. This article elaborates on the concept of non-blocking socket programming and its allied areas, with appropriate examples.

Overview

There are different types of sockets and their types are classified according to their communication properties. The communication properties are defined by the protocols they support. Usually, it requires a same type of sockets to establish any sort of communication because the standard set of rules for transferring data is defined by the protocols they use. The protocols are TCP or UDP. The application program specifies the protocol it supports. Typically, an application program supports more than one protocol because the programmer who has written it provided the required code to support the particular socket type in this domain. If you have been wondering the type sockets supported by the TCP/IP, they are as follows:

Both blocking and non-blocking sockets have their uses, but, blocking sockets are more common because they are easy to handle and are the default choice of socket programming in Java. To put it in a simple manner: In a blocking socket program, lines of code execute one after another but they get blocked or halt at the instruction where system calls are made. It waits there until an appropriate reply is received, timeout occurs, or some error is encountered. The non-blocking socket program, on the other hand, does not wait for the reply and continues execution even though the call may not have been completed. Any incomplete reply from invoked system call is dealt with separately.

Use of Blocking vs. Non-blocking Sockets

The blocking sockets are appropriate for a situation where a reply from the system call is crucial. For example, assume a client program wanting to connect to a server. The program must be responsive only when the connection is established or some error has occurred. This means the socket must be blocking user control until an appropriate reply has been received.

Ø  Email Article

Ø  Print Article

On the other hand, consider that a client is trying to establishing multiple connections and each connection can be made exclusive of another. In such a case, the socket must not be rigid to block another system call to establish the connection. This is a scenario for non-blocking sockets.

Non-blocking Sockets in Java

Java has TCP and UDP sockets. The methods such as connect(), accept(), read(), and write() defined in the ServerSocket and Socket class are used for blocking socket programming. For example, when a client invokes the read() method to read data from the server, the thread gets blocked until the data is available. This situation is undesirable under some circumstances. Instead, what we can do is use the waiting period to do some other task. The client socket then can notify when the data is available. Another problem is that, in a multi-socket connection, each client is a separate thread. Therefore, there is an overhead of maintaining a pool of client threads.

Blocking sockets are simple due to their sequential execution. Non-blocking sockets, on the other hand, are non-sequential. They require a different perspective to implement them in programming. In a way, non-blocking socket programs are a little complex and a bit more advanced technique of socket communication.

Non-blocking Socket APIs

The classes that support non-blocking socket communication in Java are as follows.

(*) Refer to the Java API documentation for more information.

How It Works

The Selector class object acts as an interface between remote clients and the server in the following manner.

Figure 1: The Selector class object

The way to create the selector object is by calling its open() static method:

Selector selector=Selector.open();

The ServerSocketChannel instance, which listens to the new connection request from the client, is created in a similar manner by invoking its static open() method:

ServerSocketChannel serverSocketChannel=ServerSocketChannel.open();

The channel thus created is by default is in a blocking state. We must set it to an unblocking state explicitly in the following manner:

serverSocketChannel. configureBlocking(false);

The server socket channel must be bound to an IP address and a port number so that the client socket can communicate:

InetAddress ip=InetAddress.getByName("localhost");

serverSocketChannel.bind(new InetSocketAddress(ip, 1234));

Now, the server socket must register itself with the selector. The selector acts as a multiplexor of selectable channels. This primarily means selectors registration of a specific operation. The SelectionKey class integer constraints to designate each operation. For example:

·         SelectonKey.OP_CONNECT: Designates connect operation progress

·         SelectonKey.OP_ACCEPT: Designates client request for new connection

·         SelectonKey.OP_READ: Designates ready to read some data

·         SelectonKey.OP_WRITE: Designates ready to write some data

The registration is done as follows:

ServerSocketChannel.register(selector, SelectionKey.OP_ACCEPT);

The selector is now ready to intercept a client socket connection and relay to the server socket channel.

A Quick Example

This is a simple implementation of an echo server using a Java non-blocking socket channel.

Conclusion

This is a glimpse of what a non-blocking socket channel is and how to implement it in Java. Apart from providing some extra classes by the Java API library which specifically address the issues of non-blocking socket programming, the implementation is more or less similar to normal socket programming. In relation to this, there are classes that support asynchronous socket channels. We'll take them up in a separate article.