3

I am trying to understand how the VNC mechanism works.

The RFB protocol 3.8 specifications say :

The update protocol is demand-driven by the client. That is, an update is only sent from the server to the client in response to an explicit request from the client. This gives the protocol an adaptive quality. The slower the client and the network are, the lower the rate of updates becomes. With typical applications, changes to the same area of the framebuffer tend to happen soon after one another. With a slow client and/or network, transient states of the framebuffer can be ignored, resulting in less network traffic and less drawing for the client.

It seems that this implies that the server will only ever send a FramebufferUpdate if the client sends a FramebufferUpdateRequest. Then the client must be sending these packets at a regular interval. However, when I analyzed through wireshark, I observed that this was not the case. When there was no screen or pointer activity, I did not see any packets from the client to the server.

When I created some screen activity on the screen without involving the client, (I ran xclock by setting display to that value) the first message was from the server to the client and not a request from the client.

So my question is: Is it indeed true that the server will only send updates if the client requests them and not every time there is screen activity? What is the frequency of updates in either case?

  • How many clients and servers did you test this on? It's possible (probable even) that some clients and servers have nonstandard features like this. – Kevin May 16 '12 at 14:42
  • @Kevin I tested on a single client and server. I used tightvnc for both – AnkurVj May 17 '12 at 6:34
0

I realize that this is an old question, but the answer is found in the RFB RFC.

When the client sends a FramebufferUpdateRequest message to the server that is marked as incremental, that request will remain pending on the server until there is actually a change to report. At that point, the server will send back a FramebufferUpdate message containing the rectangle data with changes.

What this means is that, if you look at your network data, you will likely find that (other than keepalives, perhaps), the last packet goes from the client to the server and is a FramebufferUpdateRequest that is marked incremental. The server will not send a response until there is an update to send, so the network will remain quiet.

More commonly, the screen is changing frequently, which can lead to multiple sequential FramebufferUpdateRequest messages resulting in a single composite FramebufferUpdate message from the server.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.