Proposal for RFB 003.004

Jens Wagner jwagner "at" hexonet.de
Thu, 03 Aug 2000 12:36:44 +0000


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.

I don't see the problem. Handshaking begins with the server sending its
protocol version. If this version is "RFB 003.003\n", the client will
never send a QueryFeatures message, the complete connection will stay RFB
3.3 compatible.

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

Implementations are not required to provide any new features.
New color depths are very important for devices like the palm (4bit) and
some mobile phones. I don't think that we'll need that much code, a
single color conversation function should be sufficient for a server, if
clean implemented.
You're right, the value of rfb is simplicity, especially for the clients.

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

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

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

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

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

Maybe there should be possibility to request encoding numbers by name, as
for features. That way a client could ask the server what encodings are
supported and set the encoding numbers on the fly.

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

Good luck with it!

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