[Standards] Idle sreams in RFCbis

Nicolas Vérité nicolas.verite at process-one.net
Mon May 25 10:51:29 UTC 2009


On Mon, May 25, 2009 at 12:40 PM, Mickael Remond <
mickael.remond at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20090525/fc51a9a7/attachment.html>


More information about the Standards mailing list