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

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Wed Jun 17 20:42:19 UTC 2009


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.

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.

> > 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.

-Justin



More information about the Standards mailing list