Re: [Standards] Idle sreams in RFCbis
Please move all discussion of the bis drafts to x...@ietf.org: https://www.ietf.org/mailman/listinfo/xmpp -- Joe Hildebrand -Original Message- From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On Behalf Of Nicolas Vérité Sent: Friday, June 05, 2009 2:34 AM To: standards@xmpp.org Subject: Re: [Standards] Idle sreams in RFCbis What about that small proposed change? On Mon, May 25, 2009 at 11:31 AM, Nicolas Vérité wrote: > Hi, From: > "The sending of such a space character is called a WHITESPACE PING." To: > "The sending of such a whitespace is called a WHITESPACE KEEPALIVE." -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] Idle sreams in RFCbis
What about that small proposed change? On Mon, May 25, 2009 at 11:31 AM, Nicolas Vérité wrote: > Hi, From: > "The sending of such a space character is called a WHITESPACE PING." To: > "The sending of such a whitespace is called a WHITESPACE KEEPALIVE." -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
Re: [Standards] Idle sreams in RFCbis
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
Re: [Standards] Idle sreams in RFCbis
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). -- Mickaël Rémond http://www.process-one.net/
Re: [Standards] Idle sreams in RFCbis
2009/5/25 Artur Hefczyc : > Hi, > >> I would like to provide feedback on these two sections: >> >> 5.7.3. Handling of Idle Streams >> >> http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#streams-close-idle >> >> 12.7. Whitespace >> >> http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#xml-whitespace >> >> >> In 5.7.3, it says: >> "The typical method for detecting an idle TCP connection is to send a >> space >> character (U+0020) over the TCP connection between XML stanzas, which is >> allowed for XML streams as described under Section 12.7 (Whitespace)." >> >> Strictly speaking: >> - the sending entity does not detect the loss of connection when it sends >> whitespaces > > I think you are not right here. From my experience the sending entity only > can > detect connection loss not the receiving. > This is because sometimes TCP/IP doesn't get notified of simple connection > loss if there is no data transmission over the link. > 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. > > Artur > That's right, but from my experience the timeouts are waay too long to be useful.
Re: [Standards] Idle sreams in RFCbis
Hi, I would like to provide feedback on these two sections: 5.7.3. Handling of Idle Streams http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#streams-close-idle 12.7. Whitespace http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#xml-whitespace In 5.7.3, it says: "The typical method for detecting an idle TCP connection is to send a space character (U+0020) over the TCP connection between XML stanzas, which is allowed for XML streams as described under Section 12.7 (Whitespace)." Strictly speaking: - the sending entity does not detect the loss of connection when it sends whitespaces I think you are not right here. From my experience the sending entity only can detect connection loss not the receiving. This is because sometimes TCP/IP doesn't get notified of simple connection loss if there is no data transmission over the link. 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. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
Re: [Standards] Idle sreams in RFCbis
2009/5/25 Nicolas Vérité : > > Strictly speaking: > - the sending entity does not detect the loss of connection when it sends > whitespaces That's correct. > - the receiving entity detects the loss of connection only if it has a > mechanism that detects the absence of whitespaces Not really. It is not required to send them, so you could be terminating a live connection. Otherwise I fully agree with you. Whitespace sending is a mechanism for keepalive, not a failure detection, and certainly not a ping. I'm not sure but I think that can be done with TCP somehow? Even as a request-response mechanism. Does anyone have some experience with that?
[Standards] Idle sreams in RFCbis
Hi, I would like to provide feedback on these two sections: 5.7.3. Handling of Idle Streams http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#streams-close-idle 12.7. Whitespace http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#xml-whitespace In 5.7.3, it says: "The typical method for detecting an idle TCP connection is to send a space character (U+0020) over the TCP connection between XML stanzas, which is allowed for XML streams as described under Section 12.7 (Whitespace)." Strictly speaking: - the sending entity does not detect the loss of connection when it sends whitespaces - the receiving entity detects the loss of connection only if it has a mechanism that detects the absence of whitespaces Thus I propose this change: "The typical method for maintaining a TCP connection is to send a space character (U+0020 [...]" What do you think ot it? Then, we have: "The sending of such a space character is called a WHITESPACE PING." Strictly speaking: - a ping mechanism is a request-response mechanism, it waits for a "pong" response, so this is not a ping, and I think this should better be named a "keepalive" (or sort of) - s/space character/whitespace/ because: 1.3. Conventions http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-09.html#intro-conventions "The term "whitespace" is used to refer to any character that matches production [3] content of [XML], i.e., any instance of SP, HT, CR, and LF." Thus I propose this change: "The sending of such a whitespac is called a WHITESPACE KEEPALIVE." What do you think ot it? Regards -- Nicolas Vérité - ProcessOne http://process-one.net Mobile: +33 6 20 88 63 04
