RFB Protocol

Andrew van der Stock ajv "at" greebo.net
Mon, 14 Jan 2002 23:40:27 +0000

Absolutely - the server and clients exchange information at the beginning of
the session about their capabilities, and both are required to degrade
gracefully. The more features that are there, the more efficient the network

Just let me know a section you want to work on, or things that would really

* documenting all the current display protocols in Augmented BNF form (see
RFC2234 for more details). The current textual information in the draft (and
the RFB 3.3 document) is insufficient for a clean-room re-implementation. We
shouldn't require the client or server code hanging around to make another
client or server.


The current stuff is in Word as it's an excellent word munger. I'm happy to
be the editor and accept text in pretty much any format (prefer just plain
text e-mail) until near the end, when the challenge for me is to convert the
draft into a pure-text document (Word, docbook SGML, XML, KWrite,
Postscript, PDF, etc are not acceptable formats for IETF submission).


----- Original Message -----
From: "Erlichmen, Shay" <Shay_Erlichmen "at" icominfosys.com>
To: <vnc-list "at" uk.research.att.com>
Sent: Monday, January 14, 2002 9:39 PM
Subject: RE: RFB Protocol

> Hi,
> I think that clients should be thin, but the server shouldn't, meaning
> features like fonts, bitmap caching,  server side updating,  etc, should
> done as long as the client support it using some sort of extension
> mechanism.
> What ever you need you got my help.
> Regards,
> - Shay;
> -----Original Message-----
> From: Andrew van der Stock [mailto:ajv "at" greebo.net]
> Sent: Monday, January 14, 2002 1:48 AM
> To: vnc-list "at" uk.research.att.com
> Subject: Re: RFB Protocol
> I've been working for some time on VNC 4.0 (or something). The
> for this is at:
> http://www.evilsecurity.com/vnc/
> Major features of 4.0:
> * Backwards compatible for authentication, so no new tcp ports required
> * "Channels" - sound, file transfers, local printers, clipboard, etc out
> 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
> / Kerberos / RADIUS / PAM / PKI authenticators without limitation
> * footprint: modular & scalable - All channels and verbs can be excluded
> clients do not have to implement all features, allowing a very small (even
> smaller than today) clients, ie view only clients with minimal
> 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
> (without known keys), other encryption algorithms as desired (per channel
> only; crypto becomes tractably breakable if lots of small packets with
> 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
> 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
> 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
> not speak ASCII)
> * finishing the dang thing :)
> Cons of 4.0
> Protocol is not backwards compatible with 3.x (unavoidable), but due to
> way I've forced 4.x clients to contain at least a stub of 3.x
> along with 3.x compatible initial authentication, this is not a problem.
> 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
> and tractable using Yacc etc for the language purists). If they are
> 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 :-)
> Andrew
> ----- 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
> that
> > >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
> system.
> >
> > 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--
> M++$
> >            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
> ---------------------------------------------------------------------
> ---------------------------------------------------------------------
> 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