On Mon, May 25, 2009 at 12:40 PM, Mickael Remond < mickael.rem...@process-one.net> wrote:
> Hello, > > Artur Hefczyc wrote: > > Only when you attempt to send some data, even a single character, the > > TCP/IP > > stack tries to deliver it to the destination address. Of course if the > > connection > > is broken, the attempt fails and an error is returned to sending > > application. > > No, it is not correct. If you try to send a character, the application > will send that data to the TCP/IP layer, that will put the data in the > TCP/IP cache. The data will have left the application and the send will > be successfull. It does not mean that the receiving party has received > it. It is an asynchronous process. > The client connection will have a failing TCP send only if the TCP/IP > buffer is full after a given timeout. > > Now, the TCP/IP connection can be broken and the TCP/IP stack might > struggle for quite a long time (resending, etc), before knowing / > acknoledging it is actually broken). Under some condition, the OS layer > will not issue a TCP connection close event, until a time out is > reached. > In this case it will take a long time before the application > know the connection is lost. > > The more specific equiment you have to pass, the more the problem can > happen (for example on mobile where this is built-in to make the device > more tolerant to loss of connection). > My point was the spec RFCbis: how should we update it? Apparently, the whitespace keepalive is used in Psi and Gajim as a sending entity, at least, and maybe in other clients, especially mobile ones, I don't know for the server-side behaviour(s). -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
