Hello, TL;DR: I'm having an issue handling disconnects in Guacamole.Client/WebSocketTunnel (common-js). I think the tunnel implementation only goes one way in the state change, i.e. it doesn't change state to CONNECTING when issuing a connect, causing a state change to CLOSE to leave the tunnel in a state that eventually forces a complete replacement of the Guacamole.Client instance.
I'm asking on the dev mailing list because I'd like to contribute a fix, but it might also be intentional. Should I open a JIRA issue first? -- We're using Guacamole in our application (common-js and guacd, the proxy is our own small implementation around GuacamoleWebSocketTunnelEndpoint), but I'm having a slight issue handling disconnects. The purpose is to make the client retry connections infinitely until it succeeds. After a successful connection, I forcefully kill the proxy to fake a disconnect. No matter what I do, I can't get it to "reconnect" and I end up replacing the entire Guacamole.Client instance. I think the problem is in the Tunnel implementation for WebSocket (I suspect it's the same issue for HTTP as well). What I do is listen to state changes on the tunnel, and when the state changes to "CLOSED", I issue a connect to the Guacamole.Client (after some delay). I'm not getting a state change for this second connect call (I believe it's supposed to be CONNECTING). Since the state stays CLOSED, the second failure never notifies me and I can't know of the state change, i.e. that it failed again. Specifically, this line http://guacamole.incubator.apache.org/doc/0.9.13-incubating/guacamole-common-js/Tunnel.js.html#line693 is always true after the first state change to CLOSE. There's nothing in the WebSocket implementation that changes the state to CONNECTING. The CONNECTING state is just the initial one from the base Tunnel class. This is not true, for example, for the new Static tunnel, which sets the state to CONNECTING when connect() is called. Thanks for the help, Or.
