Hi John, I'm sure that in theory everything is really complex, but in practice when the client disconnects the TCP socket a "Socket closed" IOException will be trown on the server.
/marc On Thu, 14 Aug 2008, John D. Mitchell wrote: > On Thursday 2008.08.14, at 05:04 , Marc Larue wrote: > [...] > >I think guaranteed delivery is what TCP was designed for > > Everybody should really read W. Richard Stevens' books on TCP/IP that I > mentioned (and the various standards documents). > > TCP does *not* guarantee delivery -- it makes a best effort. TCP uses e.g., > the ACKs to notify the sender that everything up to a certain position in the > stream has been received. That's "transactional" but there can be a whole lot > of data in-flight that can get dropped. > > TCP does guarantee ordering of the stream of bytes that are received but > that's also a very different thing. > > >and HTTP/1.1 reuses the TCP socket. > > The HTTP/1.1 protocol supports keepalives but there are practical details in > the implementations and configs that may or may not give you the behavior that > you think you're getting from that. > > >You do not need to write something to a TCP socket > >to see if it is writeable, the socket throws an exception if it closes or > >becomes unwriteable. You will "know if a client disconnected" in > >real-time. > > False. The states of a socket connection are more complex than that. > > Alas, all too many people believe similar nonsense and so we (users) end up > getting stuck with software that breaks in odd ways for no good reason. > > Take care, > John >
