Addition to RFB protocol?

Steve Cheng elmert "at"
Wed, 15 Jul 1998 17:30:43 +0000


> I've looked through the protocol document, and unless I'm deeply
> misunderstanding something, there's a bit missing: why isn't there a
> message for the client to send to the server to request areas of screen
> that might have changed since it last asked?  The server could then return
> a rectangle, or number of rectangles, for which the client could ask to be
> sent the actual framebuffer data.  This keeps with the idea that it's
> still a client-driven protocol, though I think it'd be faster if the
> server pushed rectangles incrementally at the client (i.e. the server
> stops sending 'area changed' messages if the whole screen changed, and the
> client still hasn't requested an update).

> Matthew -
> I think you *have* missed something :-)  This is the basis of the protocol:
> the client sends a request for any changes, and the server returns them.  If
> there haven't been any since the last request, the server remembers this
> 'pending' request, and sends the next changes that happen.
> The client can also send a request for the *whole* screen, for example when
> it first connects, but (depending on the client) may be used at other times
> as well.

This reminded me of something I noted a short while ago on the PDF protocol

# Note however that a single FramebufferUpdate may be sent in reply to
# several FramebufferUpdateRequests.

# In the case of a fast client, the client may want to regulate the rate at
# which it sends incremental FramebufferUpdateRequests to avoid hogging the
# network.

The above sections imply that the client continually sends
FramebufferUpdateRequests to the server (regulating the rate...), and if the
specified area has not changed and the client has set the incremental flag,
the server simply ignores the request (single FramebufferUpdate can be replying to
several FramebufferUpdateRequests...) -- not "remembering" it, since it
would still know to update when the next request comes around. 

The above is not the current implementation (at least in either the VNC X
server and my GGI VNC target), and it is much more sane that way, since the
client could just block waiting for changes, rather than continually sending
FramebufferUpdateRequests, hogging the network.  This is how a typical
desktop environment works anyway.

# Note that there may be an indefinite period between the
# FramebufferUpdateRequest and the FramebufferUpdate."

This is contrary to what the previous section implies and is correct.  If
the server has received *ONE* incremental FramebufferRequest, it can delay
sending the FramebufferUpdate until the requested area has changed.

Note that non-incremental FramebufferUpdateRequests don't work this way; the
server should indeed send the full update "as soon as possible" rather than

(Matthew: might this be the source of your confusion?)

I wonder this is a leftover mistake from earlier versions of the RFB
protocol?  Or just a documentation error? :-)

Speaking of documentation errors, on page 22 of the PDF documentation, about
the structure of the CoRRE encoding, it says that the x, y, width and height
fields of a CoRRE sub-rectangle are of CARD16, but it is actually CARD8. 
The number of bytes taken by each field is shown as 1 though, which is
correct. :-)

Steve Cheng               

email: steve "at"   
www: <>

The VNC mailing list     -   see