Proposal for RFB 003.004

Const Kaplinsky const "at"
Thu, 03 Aug 2000 11:38:45 +0000

>>>>> "JW" == Jens Wagner <jwagner "at"> writes:

JW> What about the following? (my native tongue is NOT english)

JW> Proposal for RFB 003.004 same as RFB 003.003, but with the
JW> following changes and additions:

JW> - the protocol version is "RFB 003.004\n"
JW> - the colour depth / bits per pixel can also be 4, 2 or 1, with 2,
JW>   4 or 8 pixels
JW> per byte.

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.

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> 5.2.10 EnableZlibCompression

JW> Feature string: "ServerZlib"

JW> Asks the server to activate zlib compression for the complete
JW> server->client data stream.

JW> --------------+-----------------+-------------------
JW>  No. of bytes | Type [Value] | Description
JW> --------------+-----------------+-------------------
JW>  1 | CARD8 | message-type 1 | | compression-level
JW> --------------+-----------------+-------------------

JW> message-type must be set to the value defined for "ServerZlib".
JW> compression-level is used to init zlib compression.

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.

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

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

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

With Best Wishes,
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at"
See also: