[Standards] Use of XEP-0198 resumption under adverse network conditions
thilo at eightysoft.de
Sun Nov 8 11:36:41 UTC 2020
Georg, you seem to forget the push that is involved.
I think most of your depicted problems would go away if the client would send
a (XEP-0198) ping upon receiving a push and, if that ping does not succeed,
decide that the connection is dead.
That way it won't stick to an old half-dead connection but still use that old
connection if it remained usable.
No second stream needed in this scenario.
Am Freitag, 6. November 2020, 18:41:15 CET schrieb Georg Lukas:
> Hi Dave,
> * Dave Cridland <dave at cridland.net> [2020-11-04 12:48]:
> > TL;DR: When the session has a ping timeout, do push notifications, but
> > otherwise leave it open - mobile clients will often recover after several
> > minutes have passed.
> That's a great analysis and I haven't considered this situation yet, but
> your proposal sounds very logical to me.
> I see two potential issues:
> the client needs to mirror this logic as well, and stick to an old TCP
> session for a much longer time. I fear there will be some pathological
> situations where it will render the client effectively disconnected,
> e.g. when the old connection gets blackholed, but a new one could be
> established any time.
> Furthermore, some long time ago I've seen situations where a TCP
> connection had a very hard time recovering from intermittent packet
> loss, where the connection's latency remained very high and throughput
> very low. Did you experience this effect as well, or is this just a
> faint memory from times of much worse congestion control algorithms?
> To solve either problem, I can imagine that a client *could* open a
> second stream to the server in parallel to the existing one, and if the
> second stream completes authentication, then just 0198-resume there.
> But this is also going to increase medium contention, and it's even more
> sockets for the client to juggle around.
More information about the Standards