#1417 TightVNC viewer blocks while waiting for Server Frame Buffer response

[Jenna L May]

TightVNC Viewer sends a request to the TightVNC server to refresh the local frame buffer and it will indicate if a partial or full update is requested. This can be seen in Wireshark as "03 00 00 00 00 00 04 03 00" and as described succinctly here: https://tools.ietf.org/html/rfc6143 in section 7.5.3. Once that request is made – until the response is received by TightVNC viewer no further client framebuffer update requests will be sent by TightVNC Viewer. Clicking the "refresh" button will not produce another client framebuffer update request either. This means that if for some reason the server framebuffer update is not received by TightVNC Viewer – the screen will be effectively "frozen" forever. A simple workaround for this might be to send the client framebuffer update request (RfbFramebufferUpdateRequestClientMessage::send(RfbOutputGate * output)) when the user clicks the 'refresh' button regardless of whether or not there is a client update request outstanding.

[Anton]

There is no so many reason to lost framebuffer update, only one, i think - error in design of server.
Server should close socket if it can't send a message. If it will begin to send another update befor the end of previous we will get a desync.
UpdateRequest - update loop is closely connected to RFB protocol nature.