GUACAMOLE-2118: Signal end of user input to connection processes. - #699
Conversation
|
Thanks @Heyzi - one request, since this Jira issue is slated for 1.6.1, could you rebase against the |
The Docker build is broken for everyone right now. libwebsockets v5.0.0 turns on HTTP/3 by default, and HTTP/3 force-enables guacd only uses libwebsockets for Kubernetes and doesn't need HTTP/3, so adding this to Alternatively, pinning to the 4.x series on line 57 works too, and still picks up the newest 4.x release: Want me to open a PR, or would you rather take it? |
Thanks for the info on that - I'll put in a separate Jira issue for it, at least, and you can open a PR for it if you want. I don't have a terribly strong preference on direction at this point - disabling HTTP3 seems fine to me, but good either way. |
Opened GUACAMOLE-2315 for this build issue. |
Once no further data can be read from a user, the thread forwarding that user's input simply returns, leaving its end of the socketpair shared with the connection process open. A user which vanishes without sending "disconnect" therefore leaves that process blocked awaiting input indefinitely: nothing further informs it that its last user has left, so it never stops itself and never exits. The thread reading from that process cannot detect this either, as it remains blocked on a socket which an idle process will never write to again, and so never reaches the point at which it would close its end. Shut down the write side of the socketpair when no further user input is possible, such that the connection process observes end of input.
3 participants
Once no further data can be read from a user, the thread forwarding that user's input simply returns, leaving its end of the socketpair shared with the connection process open. A user which vanishes without sending "disconnect" therefore leaves that process blocked awaiting input indefinitely: nothing further informs it that its last user has left, so it never stops itself and never exits.
The thread reading from that process cannot detect this either, as it remains blocked on a socket which an idle process will never write to again, and so never reaches the point at which it would close its end.
Shut down the write side of the socketpair when no further user input is possible, such that the connection process observes end of input.