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