Users now and then have the issue that their connection is killed if they leave their session idle for too long. If this is configured by the admin (MaxIdleTime and friends) then this is expected and desired. However it also sometimes happens because of network infrastructure. Commonly a firewall that wants to get rid of stale stuff in its connection tracking. Commonly this results in a TCP RST, which looks like this in the client log: > 2022-03-14T11:05:59: ssh[E]: SYSTEM ERROR: 10054 or on Linux: > 2022-03-14T11:05:59: ssh[E]: SYSTEM ERROR: 104 The user then gets an error popup (since bug 7479) and is forced to start the client and log in again. Strictly speaking this is not a ThinLinc problem, but a problem with the network. But we could consider implementing workarounds. E.g. TCP keep alive, or something equivalent on the application layer.
Also note bug 4799 which would make reconnecting easier if this happens.
OpenSSH has such a feature, both in the client and the server. See ClientAliveInterval for server, and ServerAliveInterval for the client. This can probably be used for the native ThinLinc client. It won't help Web Access though. TLS has the extension heartbeat (known for the heartbleed bug). RDP has keep alive messages (search for KeepAliveEnable). ICA (Citrix) also has keep alive messages. And on the lower layers there is TCP keep alive. (HTTP also has something called keep alive, but it's not the same thing) Note that all of these are disabled by default, which makes we worried there is a major downside to these things. For mobile devices this could cause battery drain by forcing the device to wake up. But that is probably not too relevant for us (or RDP or ICA). There is also the concern that the network administrator *wants* to kill these connections. So adding a feature like this would be a tool to violate system policy.
