Protocol Changes (was: Zoom / Scaling in VNC)

[Jens Wagner]

Brandon Ibach wrote:

> Quoting Jonathan Morton <chromi "at" cyberspace.org>:
> > Very interesting...  The cheif problem with the existing protocol, as I see
> > it, is that the current method of indicating the presence of a feature is
> > very terse, consisting simply of a list of numbers.  This of course
> > necessitates the provision of a look-up table, which partly stifles the
> > addition of new features due to fear over conflicts.
> >
>    Initially, I was against something like this, as it would require
> more work on the part of the protocol handlers.  However, upon
> reflection, it wouldn't require *that* much extra work, and it does,
> in fact, provide some flexibility, in that someone working on an
> experimental feature can very easily come up with a unique name.

When using names, why not using a naming scheme like used in email headers?
There would always be a officially supported set of message-type-names, and
experimental/private names start with "X-"

> > I don't think that we need a new version. As far as I know there is a
> > rfb-client-server-message called setEncodings [5.2.3]. It is used by the
> > client to tell the server which encodings it will support for
> > framebuffer
> > updates, e.g. CopyRect, Hextile and so on.
> > Why not define a new encoding, e.g. 255 ? This wouldn't specify an
> > framebuffer encoding but  tell the server that the client supports a
> > special message-type, e.g.  255, with the following structure:
> >
>    This sounds like a good approach, but I see two problems.  First,
> one of the reasons to change the protocol is to add a length field to
> each message.  I think this is particularly important for the purposes
> of VNC proxies, which may want to pass certain types of messages on
> without looking inside them.  Especially in the case of framebuffer
> updates, this can't currently be done without decoding the whole
> message to determine the length.

This is *exactly* why I designed my proposal like that!
Again this is the message structure:

ExtensionMessage

No. of bytes    Type    [Value]    Description
1               CARD8   255        message-type
1               CARD8              padding
2               CARD16             ext-type-len
4               CARD32             ext-data-len
ext-type-len    CARD8 array        ext-type
ext-data-len    CARD8 array        ext-data

Just to make it clear: this is not a framebuffer update (but it could be used as
one), it is a seperate message type which is/can only be used when both client
and server support it.
It is meant to be a universal extension-message. It has a length field, it even
has got TWO. The message is always (8 + ext-type-len + ext-data-len) bytes long.
Every proxy just reads the first 8 bytes, computes (n=ext-type-len+ext-data-len)
and read the last n bytes.
The first dynamic-length-field, ext-type, is the type of the extension message.
This can be e.g. "resize-request\n", "zoom-request\n",  "X-Printer-Service\n" or
anything else. The second dynamic-length-field, ext-data, contains the type
dependent data, e.g. the requested size.
A proxy can support ExtensionMessages without to care about its content.

>
>    Secondly, a new encoding type is not the same as a new message
> type.  A new encoding type just provides a new option for the content
> format of a framebuffer update message.  Creating a new message type,
> as you're demonstrating here, is the same as changing the protocol.

I don't think so. Clients will just `abuse' the setEncodings-message to let the
server know that they support extension messages. That has absolutely nothing to
do with framebuffer updates. Older v3.3 servers don't recognise this encoding.
So they will never send a ExtensionMessage, and the extensions of the clients
will never get activated. Servers that recognise the hint will send an
activation message to the client. Now the client can be sure that
ExtensionMessage is supported by the server [and by the proxies between] and use
it itself.

The version will remain "v3.3" - it is compatible with v3.3 both on client- and
server-side.

>
> Quoting Jonathan Morton <chromi "at" cyberspace.org>:
> > Might I make a further suggestion, namely that servers should, where
> > possible, retain compatibility with the current v3.3 protocol so that our
> > existing user-base can perform a smooth upgrade...  this is less of an
> > issue for clients but would be desirable at that end as well.
> >
>    This should be quite easy.  The first messages exchanged in the
> current protocol contain protocol version information.  Thus, a 4.0
> client or server should be able to drop back to the 3.x protocol.  If
> written well, the application should have a separate "layer" to encode
> and decode the messages in the appropriate protocol version, providing
> the next layer up (which would actually do something with the message
> contents) with the same data, in the same form, regardless of the
> protocol being used.

There is no extra effort being needed when done my way.



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