Proposal for RFB 003.004

Const Kaplinsky const "at" ce.cctpu.edu.ru
Thu, 03 Aug 2000 20:47:00 +0000


>>>>> "JW" == Jens Wagner <jwagner "at" hexonet.de> writes:

JW> Const Kaplinsky schrieb:

>> 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.

>> 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...

>> Let me express my point of view on zlib compression. First of all,
>> it's not very good idea to compress the whole server->client
>> stream: compression works good when the data is statistically
>> homogeneous. The compression efficiency could degrade on server
>> message headers.

JW> I must to say that I designed the proposal it in a way that makes
JW> it easy for upgrading current rfb software. If the client queries
JW> the feature on message-type number 10, it will exacly behave as
JW> Warrens zlib implementation.

But I'm sure that we should choose the only method of many ones
providing the same functionality. And my opinion regarding zlib
compression is such that zlib implemented as encoding is prefferable.
And it already works and in the same time does not break any
compatibility.

>> And there is a way to implement zlib compression the way which do
>> not require any protocol changes. If zlib compression is made as an
>> encoding, it (1) could be done efficiently and (2) it will not
>> break compatibility. For implementation example you might want to
>> look at the TridiaVNC distribution. Unfortunately, I don't know who
>> are original authors of their zlib implementation, but zlib
>> encoding is implemented mostly "the right way" there. It breaks
>> nothing: old clients are fully compatible with new servers and new
>> clients are fully compatible with old servers (of course, zlib
>> compression will be activated only when both server and client
>> support it).

JW> But didn't you say (on your homepage) that they destroy the tables
JW> between two updates and 'cause of this aren't that efficient as if
JW> the zlib stream were persistent?

I was wrong. Just wrong. By the way I did not say that at homepage:
this claim had appeared at my diary at advogato.org (after the first
look at the sources), and I've corrected myself in the same diary
later when I had to actually work with that code. They have done
everything correctly. The only thing that is questionable is the
protocol version (it has not been changed), and I'm not sure that the
change is necessary (technically -- not necessary, ideologically --
maybe yes, maybe no).

>> 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
can handle.

I'd like to explain my position more precisely: if something already
works fine, major changes need serious reasons if it affects
published, well-defined and verified protocols. And currently I don't
think the protocol needs so many global changes. Stability and
simplicity are great things. I'm not saying that progress should stop
-- I just think that part of proposed functionality could be done
without protocol changes (primarily it's about zlib compression).

>> 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. :-)

-- 
With Best Wishes,
Constantin
---------------------------------------------------------------------
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
---------------------------------------------------------------------