I've been working for some time on VNC 4.0 (or something). The documentation 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 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 :-) Andrew ----- Original Message ----- From: "Jonathan Morton" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] (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 [EMAIL PROTECTED] with the line: > 'unsubscribe vnc-list' in the message BODY > See also: http://www.uk.research.att.com/vnc/intouch.html > --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------
