[Standards] LAST CALL: XEP-0198 (Stream Management)

Philipp Hancke fippo at goodadvice.pages.de
Wed Jun 17 20:55:42 UTC 2009

Justin Karneges wrote:
> On Wednesday 17 June 2009 12:47:49 Philipp Hancke wrote:
>> Justin Karneges wrote:
>>> Are you suggesting that we should not have s2s session resumption, but
>>> you're okay with s2s acking?
>> I just don't see yet what exactly session resumption means in the s2s
>> context. s2s acking might help, although I think that s2s connections
>> are already far more reliable than it is rumored. The main problem there
>> is imo overly aggressive use of stream errors.
> True, s2s is generally more reliable than c2s.  Most c2s problems have to do 
> with wi-fi or other dodgy internet connections, or roaming clients.  In 
> contrast, servers usually stay put and have good network connections.
> I would imagine that most s2s problems are due to server 
> upgrades/modifications or failures: someone changes their DNS, reboots their 
> server, power goes out, etc.  I'll admit that session resumption after a 
> power failure may be a lot to ask for, but it's surely not impossible for 
> those that want to try.

And most problems which s2s is blamed for are probably implementations
not handling errors properly ;-)

> There's also the race condition of a server closing down an idle s2s 
> connection just as the peer sends it a stanza.  So at least this could be 
> solved by session resumption, though it's probably a rare problem to begin 
> with.

XEP 0190 (or 3920bis). The server that closes down the stream MUST
continue to process stanzas until it receives the acknowledging
</stream:stream> from the peer. Specifically this implies that you
should not use a stream error to close down a stream.

>>> Just keep the state, whatever it is.
>> The 'whatever' is the problem. Actually, I think it is just the list of
>> domains authorized to send/receive for the stream.
> It just might be that simple, hopefully. :)  I think XEP-198 should be kept in 
> mind when designing the multiplexing stuff, and we can talk about this again 
> if it turns out to be really difficult.


More information about the Standards mailing list