On Fri, 6 Nov 2020 at 17:41, Georg Lukas <ge...@op-co.de> wrote: > 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. > > I'm not sure that's true - primarily because a client is free to decide to try a new connection at any time, an option the server does not have available.
The client also is more likely to know what's happening at the physical layer (or what passes for the physical layer these days). We've broadly not seen problems with existing sessions on the same medium (ie, without a Wifi/4G change) where a new session would solve the problem. > 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. I think if the client has got as far as decided the TCP socket is unrecoverable at its end, it can just spin up a new session. If it cannot ping with the existing connection, it will not be able to establish a new one if the existing one is potentially recoverable, and vice-versa. Dave.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
