Added handshakeType to tell the server about the expected timeout is use.

[sgh]

For long latency clients then may not be able to deliver the websocket handshake before we fall back to regular the RFB protocol.

Now it is possible to set expect_ws_handshake=1 which will increase the timeout to be rfbMaxClientWait or maxClientWait if set.

[matti]

added my comments in the issue https://github.com/LibVNC/libvncserver/issues/438

[bk138]

This seems to be about configuring the server that only websockets clients will connect and in turn increasing timeout levels. Needs testing and API documentation via doc comments.

[matti]

increasing handshake wont fix this for slow networks, it just increases propability to succeed and makes ws connections to start slower

this dual mode operation should just be change to be either or

[sgh]

WS-connections start "immediately" because they transmit the handshake. Regular clients will have to wait - in this case 500ms. The proposed solution will work as long as the network delay is < 500ms. I chose that duration because it seemed fairly acceptable to normal RFB-clients and usually your ping time does not exceed 500 ms. 2G cellular networks might give you 1000 ms roundtrips but I think that VNC will be unusable on 2G. Also - the current 100ms timeout is a "probabillity thing" as well.

The overall protocol design separating RFB and WS/WSS is not optimal - therefore the catch-all solution we be as well :)

[matti]

agreed

[bk138]

Maybe introducing handshaketype makes things overly complicated: Why not simply use cl->screen->maxClientWait instead of WEBSOCKETS_CLIENT_CONNECT_WAIT_MS or introduce a rfbScreen.maxWebSocketClientWait instead of the harcoded WEBSOCKETS_CLIENT_CONNECT_WAIT_MS?