Akshay Adhikari wrote:
> THat is, if a client and server process simultaneously send (thats
> full-duplex) one window's worth of data on their connection, theyll
> deadlock, each waiting for the other to acknowledge receipt, which is not
> going to happen.
With regard to my previous post, I realised that I may have taken the
term "acknowledge" too literally.
The TCP stack will ACK the data. However, unless it is removed from
the input buffer, the sender will eventually block.
Eliminating this sort of deadlock between communicating processes is a
generic concurrent programming problem. There isn't anything about it
that is specific to TCP. The same problem exists if you are
communicating via a serial link, a pair of pipes, Unix domain sockets
etc.
The bottom line is that you cannot allow a process to block while
sending if the protocol requires that it continues to retrieve data.
Methods for avoiding this include using select(), non-blocking
(O_NONBLOCK) sockets, and multiple threads.
--
Glynn Clements <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
