RFB Protocol

W. Brian Blevins brian.blevins "at" tridia.com
Mon, 14 Jan 2002 14:04:14 +0000

Hi Jonathan,

> Date: Sun, 13 Jan 2002 14:15:36 +0000
> From: Jonathan Morton <chromi "at" cyberspace.org>
> Subject: Re: RFB Protocol
> >Does someone know, why RFB which is not fixed message size protocol (when it
> >comes to screen updates) is not defined the Following way:
> >
> >[CARD32 MessageSize]
> >[Message[MessageSize]]
> >
> >Why the protocol does not contain a Message Size field as the 1st member?
> Lack of foresight, probably.  The original developers never realised 
> that future extensions might go beyond simple graphics encodings.

While that is certainly one possible explanation, there is actually
a performance benefit to flushing partial screen updates to the
network before the entire update has been processed.  It causes the
server CPU, network connection and viewer CPU to work in parallel,
which helps lower the total response time.  This precludes putting
the size of the entire message in the message header.

Of course, this can also be achieved by limiting the maximum size of
the update region.  However, it can be problematic to guess what size
screen update will lead to a good buffer's worth of network traffic.
In addition, it is even harder to guess what size screen update will
use an appropriate amount of CPU time on the host before it makes
sense to get the network subsystem and viewer CPU started.

I'd prefer to see the message length included as well.  However, I'm
not quite ready to believe that the original designers completely
ignored the concept of a packet length.

TridiaVNC Pro: finally, affordable remote control.
To unsubscribe, mail majordomo "at" uk.research.att.com with the line:
'unsubscribe vnc-list' in the message BODY
See also: http://www.uk.research.att.com/vnc/intouch.html