I see a lot of discussion about why clients are forcibly disconnected, and the different techniques that can be implemented to manage this, one of which being to set the View environment to never forcibly disconnect client sessions (assuming of course that either a) the client supports this or b) you disable session timeouts for legacy clients via the published KB article).
What I can't seem to find is a good explanation as to why you should implement a forcible disconnect policy. I can understand a disconnect policy based on some period of idleness, but to have a blanket timeout that says "regardless if you're actively working, you will be interrupted in 10, 12, 20, etc hrs" seems ludicrous. Especially for zero clients that don't support any sort of session "keep alives", the obvious solution then is to implement the backdoor session disable for legacy clients mentioned above, especially in circumstance when we don't have a predictable "reconnect" interval. So why not just disable timeouts globally then? There has to be some reason or use case as to why it's a good idea, and I've LOVE to hear it. What's the logic behind having a non-state-aware disconnect timer? Is it to maintain adequate Connection Server performance? Is it a security feature (ie: to mitigate risk of session hijacking)? Something entirely different?
