RFB Protocol

Andrew van der Stock ajv "at" greebo.net
Sun, 13 Jan 2002 23:54:17 +0000

I've been working for some time on VNC 4.0 (or something). The documentation
for this is at:


Major features of 4.0:

* Backwards compatible for authentication, so no new tcp ports required
* "Channels" - sound, file transfers, local printers, clipboard, etc out of
the box
* client and server informational event channel - allows dynamic
re-configuration notifications (ie new input device, or display resolution /
depth changes without restarting the protocol)
* Orthagonal - you can create multiple channels of the same type (ie two
display channels to allow dual head support, etc)
* Security - my original focus - uses the The Secure Remote Password
Protocol, the most provably secure shared secret authentication mechanism
(RFC 2945), but is also pluggable using a blob authenticator, so allows NTLM
/ Kerberos / RADIUS / PAM / PKI authenticators without limitation
* footprint: modular & scalable - All channels and verbs can be excluded so
clients do not have to implement all features, allowing a very small (even
smaller than today) clients, ie view only clients with minimal capabilities.
Obviously, some combinations are less than useful, but for othagonality, I
am leaving it as is
* improved wire security - allows for 3DES and AES encryption out of the box
(without known keys), other encryption algorithms as desired (per channel
only; crypto becomes tractably breakable if lots of small packets with known
start bytes flow past an attacker, see Enigma, AirSnort et al for
demonstrable proof of this)
* improved wire speed - can indicate per verb or per channel that
compression is required (bzip and gzip out of the box)
* Will allow multiple binds to the same port for different screens, ie joe:1
and bill:2 can still work over port 5900
* Self-describing; all verbs are able to be tested for validity, allowing
the client and server to implement grammar checkers before executing the
incoming streams (mutual distrust model)
* String display (why send a 2000 - 18000 byte image when a 30 byte string
will do if both share a similar font?)
* tile cache (indicates to the client that the next verb will contain a tile
with a known hash number, and in future the server will simply state for
that tile hash to be displayed at location x,y) - this is memory / storage
dependant - *really* thin clients don't have to implement this, or can
choose to implement very small caches.

Things I'm still to work on:

* support for rootless windows (ie applications are hosted by the local
window manager) but I know where I can find the VNC client/server patches
for this support, and it's just a matter of documenting it
* Unicode string support (it's time to enter the real world, the world does
not speak ASCII)
* finishing the dang thing :)

Cons of 4.0

Protocol is not backwards compatible with 3.x (unavoidable), but due to the
way I've forced 4.x clients to contain at least a stub of 3.x authentication
along with 3.x compatible initial authentication, this is not a problem. The
incompatibility is ameriolated by using whereever possible features that
already exist from various clients (tight, tridia, Palm), with the same
protocol stream after the verb. The major change for an existing product
wishing to support the new protocol is a new authenticator and a new
protocol interpreter / grammar checker (which should be simpler than today's
and tractable using Yacc etc for the language purists). If they are clever,
they can support 3.x and 4.x verbs simultaneously with the same input /
drawing code, and then slowly add code to support more of the new 4.x
features (remember - it's all optional, so as you get around to it, it'll
continue working with previous versions of 4.x clients or servers).

I must get around to finishing it. Willing to accept help :-)


----- Original Message -----
From: "Jonathan Morton" <chromi "at" cyberspace.org>
To: <vnc-list "at" uk.research.att.com>
Sent: Monday, January 14, 2002 2:20 AM
Subject: RE: RFB Protocol

> >Ahm, can we change it?, I mean it's not SUCH a big change and I'm sure
> >all of us will support it. And we can always maintain backward
> >compatibility.
> How?  Think about all the massive set of software already using the old
> Don't answer that.  I've already thought of a way that does this
> along with a whole bundle of other stuff.  Documenting and
> implementing it would be a royal pain, however, which I don't have
> timme for.  :(
> --
> --------------------------------------------------------------
> from:     Jonathan "Chromatix" Morton
> mail:     chromi "at" cyberspace.org  (not for attachments)
> website:  http://www.chromatix.uklinux.net/vnc/
> geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O--
>            V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
> tagline:  The key to knowledge is not to rely on people to teach you it.
> ---------------------------------------------------------------------
> 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
> ---------------------------------------------------------------------
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