Subject: Re: [xmpp] #23: to error or not when handling an idle stream

From: Philipp Hancke <[email-masked]>
Date: Thu, 01 Jul 2010 14:40:00 +0200

Peter Saint-Andre wrote:
> 4.3.  Closing a Stream
> 4.3.1.  Process
[...]

FWIW I still don't think the closing handshake is applicable to stream
errors such as bad-format, invalid-xml or xml-not-well-formed.

"MUST terminate the underlying TCP connection or connections."
connection_s_?

> 4.3.2.  Handling of Idle Streams

>    An XML stream can become idle when neither entity has sent XMPP
>    traffic over the stream for some period of time.  There are many
>    reasons why a stream might be, or appear to be, idle (e.g., simple
>    inactivity or a lost network connection at a level below XMPP).

This section is a mess. You're mixing up different things:
1) idle streams in the sense used by XEP 0190:
no user data (any stanza excluding xep 0199 pings sent by the server to
test the connection) has been sent for a while. Those connections must
be closed with the 3-way-handshake. The purpose is not to have a s2s
connections up for weeks just because a single message was sent.
Note that this only applies to streams that can be reestablished and
that they're always closed by the initiating side (client).

I don't think that you need to make any specific recommendations when
the client should close the stream. "time" is not the only factor that
has to be taken into account here, for example a server may decide to
close a s2s stream after the last user with a presence subscription on
the remote domain has disconnected.

2) broken streams:
the TCP connection to the peer still exists, the initiator can
successfully write to the underlying socket, but there is absolutely no
response on the xmpp level. This is when you may send a connection
timeout error.
Unfortunately, s2s connections look much like that :-p

3) broken tcp connections:
those are characterized by a TCP socket which is no longer writeable. In
a nonblocking socket environment this can happen without giving an
obvious error. This can be detected by a keep-alive ping (even
whitespace) that gets buffered while the previous ping is still in the
write buffer. I am not sure if 3920bis has to repeat basic knowledge
about socket programming, but if anywhere this belongs into section 3.
Closing these with a connection timeout makes no sense, since the error
will not be received by the peer.

> 4.6.3.4.  connection-timeout

+1 (for the tweaked version)

---

From: Matthew Wild <[email-masked]>
Date: Thu, 1 Jul 2010 14:49:00 +0100

> "MUST terminate the underlying TCP connection or connections."

I frowned at that for a moment too, but decided it was probably
meaning a pair of s2s connections, and carried on my way.

Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Jul 2010 10:20:34 -0600

> meaning a pair of s2s connections, and carried on my way.

Yes. I didn't want the text to be taken as forbidding multiple s2s
connections.

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Jul 2010 10:32:35 -0600

> Yes. I didn't want the text to be taken as forbidding multiple s2s

In any case, I agree that "or connections" is slightly confusing, so
I've removed those two words from my working copy.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Jul 2010 11:00:52 -0600

> errors such as bad-format, invalid-xml or xml-not-well-formed.

The text does say "SHOULD", not "MUST". IMHO it would be better not to
start special-casing various stream error conditions, and instead leave
this up to the implementation.

> This section is a mess. 

Super, thanks for the blunt feedback. :)

> You're mixing up different things:

That's a helpful taxonomy. I'll rewrite the text with those categories
in mind and post again to the list.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Jul 2010 15:42:10 -0600

> in mind and post again to the list.

Here is my proposed text:

###

4.4.  Handling of Silent Peers

   When an entity that is a party to a stream has not received any XMPP
   traffic from its stream peer for some period of time, the peer might
   appear to be silent.  There are several reasons why this might
   happen:

   1.  The peer is idle and simply has not sent any XMPP traffic over
       the XML stream.

   2.  The XML stream is broken despite the fact that the underlying TCP
       connection is alive.

   3.  The underlying TCP connection is dead.

   These three conditions are best handled separately, as described in
   the following sections.

4.4.1.  Idle Peer

   If the stream peer is idle at the XMPP application layer, it is
   appropriate for the entity to simply close the stream using the
   handshake described under Section 4.3.  The timeout period is a
   matter of implementation and local service policy; however, it is
   RECOMMENDED to be liberal in accepting idle peers, since experience
   has shown that doing so improves the reliability of communication
   over XMPP networks.  In particular, it is typically more efficient to
   maintain a stream between two servers than it is to aggressively
   timeout such a stream, especially with regard to synchronization of
   presence information as described in [XMPP-IM]; therefore it is
   RECOMMENDED to maintain such a stream since experience has shown that
   server-to-server streams are cyclical and typically need to be re-
   established fairly frequently (e.g. at least every 24 hours) if they
   are timed out because the peer is idle.

4.4.2.  Broken Stream

   In this case, the peer never responds to XMPP traffic that the entity
   sends, whether normal stanzas or specialized stream-checking traffic
   such as the application-level pings defined in [XEP-0199] or the more
   comprehensive stream management protocol defined in [XEP-0198].  It
   is appropriate for the entity to terminate a broken stream using the
   <connection-timeout/> stream error described under Section 4.7.3.4.

4.4.3.  Dead Connection

   If the underlying TCP connection is dead, stream-level checks (e.g.,
   [XEP-0199] and [XEP-0198]) are ineffective.  Therefore it is
   unnecessary to close the stream with or without an error, and it is
   appropriate instead to simply close the TCP connection.

   One common method for checking the TCP connection is to send a space
   character (U+0020) between XML stanzas, which is allowed for XML
   streams as described under Section 11.7; the sending of such a space
   character is properly called a WHITESPACE KEEPALIVE (the term
   "whitespace ping" is often used, despite the fact that it is not a
   ping since no "pong" is possible).

4.4.4.  Use of Checking Methods

   Implementers are advised to support whichever stream-checking and
   connection-checking methods they deem appropriate, but to carefully
   weigh the network impact of such methods against the benefits of
   discovering broken streams and dead TCP connections in a timely
   manner.  The length of time between the use of any particular check
   is very much a matter of local service policy and depends strongly on
   the network environment and usage scenarios of a given deployment and
   connection type; at the time of writing, it is RECOMMENDED that any
   such check be performed not more than once every 5 minutes and that,
   ideally, such checks will be initiated by clients rather than
   servers.  Those who implement XMPP software and deploy XMPP services
   are encouraged to seek additional advice regarding appropriate timing
   of stream-checking and connection-checking methods, particularly when
   power-constrained devices are being used (e.g., in mobile
   environments).

###

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 08 Jul 2010 19:11:00 +0200

>     3.  The underlying TCP connection is dead.

Oh, I managed to forget case #1a: the stream is unidirectional and the 
peer is not allowed to send stanzas. I am not sure if such a peer will 
send whitespace pings... Dave?

>     timeout such a stream

+1. It may be worth mentioning that this is typically the case for 
unidirectional s2s streams (before "The timeout period..."?).

I am not sure if "for the entity to simply close the stream" and 
"RECOMMENDED to be liberal in accepting idle peers" makes it clear that 
the closing handshake is typically initated by the s2s client.

>     especially with regard to synchronization of

Too much handwaving imo ("presence synchronization", 24 hours). What 
about removing this part?

>     <connection-timeout/>  stream error described under Section 4.7.3.4.

btw: application level pings don't work for unidirectional s2s streams 
(at least not the trivial way).

> 4.4.3.  Dead Connection
[...]
+1

> 4.4.4.  Use of Checking Methods
[...]
+1

Ausgezeichnet!

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Jul 2010 16:59:01 -0600

> send whitespace pings... Dave?

We could change "over the XML stream" to "over its XML stream to the
entity", which glosses over whether the stream is unidirectional or
bidirectional (for our purposes here I don't think it matters).

> the closing handshake is typically initated by the s2s client.

By "s2s client" do you mean "peer server"?

> about removing this part?

IMHO none of that text is really achieving much, so I'd be OK with
removing it.

> (at least not the trivial way).

True. I'll see if I can find some words to finesse that issue.

>> 4.4.4.  Use of Checking Methods

:)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/