Added handshakeType to tell the server about the expected timeout is use. #455
Conversation
|
added my comments in the issue #438 |
sgh
changed the title
|
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. |
sgh
force-pushed
the
master
branch
2 times, most recently
from
b315c5b to
c4711e4
Compare
|
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 |
|
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 :) |
|
agreed |
| @@ -74,8 +74,7 @@ Connection: Upgrade\r\n\ | |||
| Sec-WebSocket-Accept: %s\r\n\ | |||
| \r\n" | |||
|
|
|||
| #define WEBSOCKETS_CLIENT_CONNECT_WAIT_MS 100 | |||
| #define WEBSOCKETS_CLIENT_SEND_WAIT_MS 100 | |||
| #define WEBSOCKETS_CLIENT_CONNECT_WAIT_MS 500 | |||
There was a problem hiding this comment.
In most use cases 500 ms is more than acceptable, but, generally speaking, we should maybe put all of these constants to a config.h.in file so that a developer could set them to their liking at compile time.
We should probably address this in a future PR, my comment is more to remember.
For long latency clients then may not be able to deliver the websocket handshake before we fall back to regular the RFB protocol. So to not introduce a multisecond delay for all conenction a handshakeType setting is introduced to tell which type of handshake we expect. The problem is that a RFB client will be quiet "forever" until the server sends it's signature. On the other hand a websocket client will send it's HTTP websocket handshake immediately. Before the server for sure know the the type of client the connect procedure cannot continue. There is no other option than to wait for some amount of time when the client type is auto detected.
|
Maybe introducing handshaketype makes things overly complicated: Why not simply use |
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.