Under the Hood - TCP/IP Sockets in Java Practical Guide for Programmers - page 98

TCP connection under control of a misbehaving program. Because these buffers are finite, they
can fill up, and it is this fact, coupled with TCP's flow control mechanism, that leads to the
possibility of another form of deadlock.
Once RecvQ is full, the TCP flow control mechanism kicks in and prevents the transfer of
any bytes from the sending host's SendQ, until space becomes available in RecvQ as a result
of the receiver calling the input stream's read() method. (The purpose of the flow control
mechanism is to ensure that the sender does not transmit more data than the receiving system
can handle.) A sending program can continue to call send until SendQ is full; however, once
SendQ is full, a call to out.write() will block until space becomes available, that is, until some
bytes are transferred to the receiving socket's RecvQ .If RecvQ is also full, everything stops
until the receiving program calls in.read() and some bytes are transferred to Delivered .
Let's assume the sizes of SendQ and RecvQ are SQS and RQS , respectively. A write() call
with a byte array of size n such that n> SQS will not return until at least n −SQS bytes have
been transferred to RecvQ at the receiving host. If n exceeds ( SQS +RQS ) , write() cannot
return until after the receiving program has read at least n − ( SQS +RQS ) bytes from the
input stream. If the receiving program does not call read() , a large send() may not complete
successfully. In particular, if both ends of the connection invoke their respective output
streams' write() method simultaneously with buffers greater than SQS +RQS , deadlock will
result: neither write will ever complete, and both programs will remain blocked forever.
As a concrete example, consider a connection between a program on Host A and a program
on Host B. Assume SQS and RQS are 500 at both A and B. Figure 5.5 shows what happens
when both programs try to send 1500 bytes at the same time. The first 500 bytes of data in the
program at Host A have been transferred to the other end; another 500 bytes have been copied
into SendQ at Host A. The remaining 500 bytes cannot be sent—and therefore out.write() will
not return—until space frees up in RecvQ at Host B. Unfortunately, the same situation holds
in the program at Host B. Therefore, neither program's write() call will ever complete.

send(s,buffer,1500,0); send(s,buffer,1500,0);

To be sent SendQ RecvQ Delivered

Delivered RecvQ SendQ To be sent

Program Implementation Implementation Program

Host A Host B

Figure 5.5: Deadlock due to simultaneous write() s to output streams at opposite ends of the connection.