Have a keepalive mechanism for the session

[middlestone]

When operating behind load balancers / ingress controllers that have
an idle timeout configured, it's common to see disconnection of the seession on the UI.
Is there any suggestion to avoid this problem? if there is a mechanism that can be used inside this project, it will be better than
changing the setting of the ingress

[tinyzimmer]

Hrm. I guess my first question would be does the ingress have any idle timeout mechanisms specifically for websockets? Second question is I assume the disconnections happen when someone isn't interacting with the UI?

Those two answers in any order produce different followups 😛. Mainly, because if someone is interacting with the UI, then it really isn't much of an idle connection. Which means the ingress is mistakenly assuming a held open websocket connection is idle even though there is data going over it.

If the connections are indeed idle when they get dropped (e.g. not interacting with the UI), then this is a tough one. All pieces are sorta doing what you are telling them to do.

[middlestone]

@tinyzimmer your reply is really quickly, :), thank you very much. About your two questions, your are right, the case here is someone isn't always interacting with UI. It is possible to setup ingress only for kvdi service via annonations, but I saw other cloud apps have keepalive mechanism for this problem, so I think is it better for this project to have such a mechanism too.

[tinyzimmer]

Unfortunately it isn't so straightforward. The display/audio connections are websockets operating strictly in binary passthrough. There is a quick custom exchange at the beginning but then it does nothing else but proxy the underlying protocol (in this case VNC or webm/opus).

To inject some form of keep-alive packets into that stream could cause a whirlwind of problems with the protocols themselves. It's worth trying out, but I don't see it behaving well. The only other way I could think of would be a side-channel, but that does not address the issue with the main channel being idle.

[middlestone]

:), thanks for your information, this problem really puzzles me, I am thinking refresh the desktop or blink the mouse periodly in the display channel is a good idea or not. Fortunately, I don't need to care about audio channel currently.

[tinyzimmer]

I mean all that's really needed is something small on the desktop UI (like a taskbar icon or something) that has its pixels change occasionally. Small such that you are still keeping traffic to a minimum.

But whether this is something kvdi should do, or the user configuring a desktop template, I'm leaning on the second.