Proposal for RFB 003.004
chromi "at" cyberspace.org
Thu, 03 Aug 2000 21:39:00 +0000
>>> While changes to the RFB protocol could be reasonable, I think that
>>> proposed changes should affect major version number of the
>>> protocol. I believe the version should be "RFB 004.001\n". The
>>> reason is provided in the original RFB 003.003 specification: all
>>> client/server combinations supporting the same major version number
>>> of the protocol should be compatible with each other. To achieve
>>> this, we should not define any new protocol messages in 003.*, only
>>> new encodings could be added to satisfy compatibility needs.
>JW> I don't see the problem. Handshaking begins with the server
>JW> sending its protocol version. If this version is "RFB 003.003\n",
>JW> the client will never send a QueryFeatures message, the complete
>JW> connection will stay RFB 3.3 compatible.
>Yes, I understand that. But protocol numbering principles are just a
>part of protocol 3.3 specification. And here is just my own point of
>view -- if I understand everything correctly, 4.1 conforms to the
>specification better in this case.
I'd say that if things can possibly be implemented in a way that uses
"encoding types", this is a Good Thing. Scaled updates can be implemented
as encoding types. Zlib has already been implemented as an encoding type,
and it works that way. View-only passwords can be implemented at the
server side without any changes to the protocol. User-specific passwords
and longer passwords are more complex, but can be implemented as a new
"authentication type" which would be regrettably incompatible with current
clients unless the functionality was switched off at the server end.
Multiple monitors can be implemented in a number of different ways, all
without changing the protocol.
I believe those are the main features being requested at the moment, all
but one of which could be coalesced into an RFB 3.4 specification with no
disruption to compatibility with the current crop of RFB 3.3 clients and
servers. The improvements to authentication are the one sticking point,
but if the 3.4 spec includes this AND notes that use of this method by the
server will render it incompatible with RFB 3.3 (implying that it should be
capable of being turned off), there shouldn't be too much of a problem.
>>> Another problem is that such protocol changes complicate protocol
>>> and potential implementations a lot. For example, I don't think
>>> that new color depth values are very useful in practice but we'll
>>> need a lot of new code to support them even if they actually would
>>> not be in use. The value of the RFB protocol is it's simplicity. I
>>> believe we should not invent new complex X-like protocol (moreover,
>>> I think current protocol is too complicated in part of dealing with
>>> pixel formats).
>JW> Implementations are not required to provide any new features. New
>JW> color depths are very important for devices like the palm (4bit)
>JW> and some mobile phones. I don't think that we'll need that much
>JW> code, a single color conversation function should be sufficient
>JW> for a server, if clean implemented.
>There are many convertation code in the server code already (at least,
>in Xvnc). Terrible multipage macros expanded for each BPP value etc...
>But of course, if 4 bits is really useful color format (I just don't
>know), and if 8 bits does not suit these needs (or maybe it does?),
>why not introduce it...
Before we introduce 4-bit support, we need to thoroughly investigate how
complex it is to encode/decode, both in terms of code complexity and CPU
power. The "target audience" is a relatively small number of PDA users,
who have limited bandwidth AND limited CPU power AND limited memory at
their disposal. If I understand rightly, it is even infeasible to
introduce Zlib encoding on these machines, simply because it is so CPU
intensive and has high code complexity. Server-side scaling is probably a
very good solution to this, but having never used one of these devices, I
don't know how beneficial 4-bit depth would be.
>>> By the way, we probably should have something like "the official
>>> list of registered numbers" for new encodings (and maybe, for other
>>> modifications). For example, it will be a good idea to assign a
>>> code to zlib compression mentioned above. TridiaVNC uses 6 as the
>>> code for their zlib compression; I think it could be a good idea to
>>> assign this number and ``-encoding zlib'' vncviewer option to that
>>> encoding ``officially''.
>JW> Maybe there should be possibility to request encoding numbers by
>JW> name, as for features. That way a client could ask the server what
>JW> encodings are supported and set the encoding numbers on the fly.
>But does it really differ from numbers? Current protocol definition
>also allows to dynamically change encodings. And I believe it's not
>necessary for a client to know all encodings supported by the server:
>the client would never see unsupported encodings anyway. ;-)
>The main point is that the server should know what features a client
The current problem is that there is no central database of encoding
numbers and their definitions, beyond the original RFB 3.3 set. Named
encodings would allow for expansion with some degree of immunity from
inadvertently using an already-allocated number, but so would a
centrally-recognised database. The database would also avoid making
changes to the protocol.
>>> I'm currently working on another efficient RFB encoding and it
>>> would be great if I could use such encoding code which will not
>>> interfere with other contributions to VNC development...
>JW> Good luck with it!
>Oh, thank you. :-)
I'd love to hear about it when it's ready. :)
from: Jonathan "Chromatix" Morton
mail: chromi "at" cyberspace.org (not for attachments)
uni-mail: j.d.morton "at" lancaster.ac.uk
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://chromatix.autistics.org/vnc/
-----BEGIN GEEK CODE BLOCK-----
GCS$/E/S dpu(!) s:- a19 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+
-----END GEEK CODE BLOCK-----
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html