[Standards] LAST CALL: XEP-0198 (Stream Management)
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
> > 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