[Standards] s2s and gracelessly broken streams

[Dave Cridland]

On Wed Apr  4 15:48:30 2007, Richard Dobson wrote:
> 
>> I would also say "don't impose a requirement to send 
>> non-information bearing octets around purely to maintain a 
>> connection", too. Basically, if you say "s2s connections MAY be 
>> timed out when idle, and such a timeout MUST NOT be lower than 30 
>> minutes", then this gets translated into implementations as 
>> "servers MUST send their peers some useless stanza every 25 
>> minutes", which - supposing we take Tony's figures - means that he 
>> might be getting or sending 3.3 of these every second on average.
> As a note though we must ensure we don't specify particular 
> required time-out periods in the specs, these should be left 
> entirely up to the implementation as if done correctly these will 
> likely be dynamically variable depending on the resource 
> utilisation on the server, i.e. if a servers resources are becoming 
> constrained it would decrease the time-out period depending on just 
> how constrained it is and also if a server is not constrained and 
> has plenty of resources going spare it would keep the connections 
> open for longer and longer periods to avoid needing to set the 
> connections up again.

Absolutely agreed.

The two things I would put in a specification somewhere is a mandate 
that servers don't reconnect purely because of a disconnection, and 
that "idle" is not related to link activity, but information flow. 
(As in, "maintaining" a connection via XEP-0198 or XEP-0199 pings is 
not possible). Of course, when really constrained, servers might want 
to cut themselves off from the outside world entirely - intra-domain 
communications will generally be more important.

The other half - figuring out if you missed something while 
disconnected - is already specified in XEP-0198.

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade