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. - tmolitor Am Freitag, 6. November 2020, 18:41:15 CET schrieb Georg Lukas: > Hi Dave, > > * Dave Cridland <d...@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. > > > Georg _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
