Orderly Versus Abortive Connection Release in Java

This article covers the following topics:

Overview

To ensure orderly or graceful release of TCP connections is a challenge with TCP networking applications. Abortive or ungraceful release may result if special care is not taken. In Java, an unexpected abortive release can manifest itself by the application receiving a java.net.SocketException when reading or writing to the socket. read() and write() normally return a numeric value indicating, respectively, the number of bytes received or sent. If an exception is received instead, this indicates the connection has been aborted and also that data may have been lost or discarded. This article explains what causes socket connections to be aborted and provides tips for avoiding the situation, except for the case where an application intends to abort the connection.

Description of the Problem

First, we need to distinguish the differences between an abortive and an orderly connection release. To understand this distinction we need to look at what happens at the TCP protocol level. It is helpful to imagine an established TCP connection as actually two separate, semi-independent streams of data. If the two peers are A and B, then one stream delivers data from A to B, and the other stream from B to A. An orderly release occurs in two stages. First one side (say A) decides to stop sending data and sends a FIN message across to B. When the TCP stack at B's side receives the FIN it knows that no more data is coming from A, and whenever B reads all preceding data off the socket, further reads will return the value -1 to indicate end-of-file. This procedure is known as the TCP half-close, because only one half of the connection is closed. Not surprisingly, the procedure for the other half is exactly the same. B sends a FIN message to A, who eventually receives a -1 after reading all preceding data sent by A off the socket.

By contrast, an abortive close uses the RST (Reset) message. If either side issues an RST, this means the entire connection is aborted and the TCP stack can throw away any queued data which has not been sent or received by either application.

So, how do Java applications perform orderly and abortive releases? Let's consider abortive releases first. A convention that has existed since the days of the original BSD sockets is that the "linger" socket option can be used to force an abortive connection release. Either application can call Socket.setLinger (true, 0) to tell the TCP stack that when this socket is closed, the abortive (RST) procedure is to be used. Setting the linger option has no immediate effect, except that when Socket.close() is called subsequently, the connection is aborted with an RST message. As we will see shortly, there are other ways that may cause a connection to be aborted, but this is the simplest way to make it happen.

The close() method is also used to perform orderly release, as well as abortive. So, at its simplest, the difference between an orderly release and an abortive release could be as little as not setting the linger(0) option, described above, prior to calling Socket.close(). Take the example of two connected peers A and B: If A calls Socket.close(), a FIN message is sent from A to B; and when B calls Socket.close(), a FIN is sent from B to A. In fact, the default setting for the linger option is to not use abortive close; so if two applications terminate their connection just by using Socket.close(), then the outcome should be an orderly release. So what, then, is the problem?

The problem is a slight mismatch between the semantics of Socket.close() and the TCP FIN message. Sending a TCP FIN message means "I am finished sending", whereas Socket.close() means "I am finished sending and receiving." When you call Socket.close(), clearly it is no longer possible to send data; nor, however, is it possible to receive data. So what happens, for example, when A attempts an orderly release by closing the socket, but B continues to send data? This is perfectly allowable in the TCP specification, because as far as TCP is concerned only one half of the connection has been closed. But since A's socket is closed there is nobody to read data if B should continue sending. In this situation A's TCP stack must send an RST to forcibly terminate the connection.

Another common scenario, which may result in an unintended SocketException, is the following: Say A has sent data to B, but B closes the socket without reading all the data. In this situation, B's TCP stack knows that some data is effectively lost and it will forcibly terminate with RST rather than use the orderly FIN procedure. A will get a SocketException if it then tries to send or receive data from the socket.

How to avoid the problem

There are a number of simple ways to avoid being surprised by this problem.

Structure data with a higher-level protocol. Protocols such as HTTP, which are built on top of TCP, deal with the issue by making it clear to both sides when it is safe to close the socket.
Always consume data from a socket before closing it. This will help avoid the second scenario described above.
Use shutdownOutput(). This method has the same effect as close() in that a FIN is sent to indicate that this peer has finished sending, but it is still possible to read from the socket until such time as the remote peer sends a FIN and end-of-file is read from the stream. Then the socket can be closed with Socket.close().