[Standards] LAST CALL: XEP-0198 (Stream Management)
stpeter at stpeter.im
Wed Jun 17 20:47:40 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 6/17/09 2:42 PM, 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.
> 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
I agree that most s2s connections are solid. However, we mustn't think
of XMPP servers only as things that live in data centers. I could run an
XMPP server on my phone or in my backpack. An airplane or ship could run
its own XMPP server for everyone on board but might lose line of sight
to the rest of the network. And believe me there are already people
doing things like this...
>>> 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.
Right. Let's implement and deploy rather than talk about hypothetical
problems. I'm sure that reality will present plenty of its own problems
for us to solve. :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Standards