Protocol Changes (was: Zoom / Scaling in VNC)

Tue, 21 Mar 2000 12:10:48 +0000

Hi!

Seeing as I started off this thread, I thought I'd chuck in my 2p.

I feel that a protocol V4 using text descriptors to negotiate capabilities at

startup and a length field in each message are extremely important. Here are

a few additional comments to throw into the mix:

1) Text descriptors will allow user-defined or global extensions to be added

to the protocol very easily. Numeric / bitmask fields almost always result in

major compatibility issues when you have a number of independent developers

wanting to modify/extend the protocol. For efficiency, each message/encoding

should be dynamically assigned a number for future use to reduce bandwidth (e.g.

a 16-bit field incremented by 1 for each type negotiated).

2) A message length field is very useful - this allows servers or clients to

skip unknown messages, or to log them for debugging purposes. At the moment,

the client or server MUST immediately terminate the connection if it gets an

unrecognised message. Similarly, if a buffer update is ever received in an unsupported

encoding, the connection dies. Again, it would be nice to be able to discard

the update, rather than immediately falling over. This may also allow us to

strip out the "padding" fields currently in the v3.3 protocol, and so would

reduce the total amount of data transmitted, despite the additional length field.

3) IIRC, the pixel formatting control is, at present, quite nasty - a SetPixelFormat

is assumed to immediately be acted on immediately. Any intermediate data may

be misinterpreted (see earlier comments regarding the proxy server). Similarly,

no verification of palletes etc. is supported. It would be nice if, for all

*control* messages, an ACK/NAK mechanism was in place. For *update* messages,

no ACK should be required, as this would place too high a latency on the protocol.

4) As a part of this, it would be good to remove as much as possible from the

hard-coded handshaking session at the start. If this functionality was moved

into a more general control message exchange, it would be possible to maintain

the connection when resolution/bit depth/scale etc. changes on either server

or client.

5) Even if it isn't implemented for now, support for sub-byte pixel widths should

be put into the protocol (1, 2, 4-bit). This will give a substantial performance

improvement for low-bandwidth connections, which I see as being a key area that

VNC protocol does not at present allow (hence scaling as well).

6) As mentioned previously, an official "v4.0" protocol will allow compatibility

with existing servers and clients. It would be quite easy to write a generic

protocol-converter that will translate v3.3 communications into v4.0 messages.

Okay, that went on for a little longer than I intended, but IMHO this is a very

worthwhile step to take to improve the VNC protocol.

Just my 2p,

Chris.

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