Protocol Changes [GENERAL]

[Jens Wagner]

Brandon Ibach wrote:

> Quoting rich "at" annexia.org <rich "at" annexia.org>:
> > The problem is that the VNC protocol isn't really very
> > extensible as it stands. I've been thinking about
> > this a lot too since I also need a way to be able
> > to extend the protocol for my own purposes.
> >
> > Things which are missing, and could usefully be added
> > if you decide to overhaul the protocol are:
> >
> > * Server -> client and client -> server negotiated
> >   `features'. Note that there are features to be negotiated
> >   in both directions.
> >
> > * Add a message length to each message so that you can
> >   easily add extra fields to messages. This allows servers
> >   and clients to synchronize with the message flow, even
> >   if they have to ignore the extra fields.
> >
>    Good thoughts.  I had suggested at some point, possibly in a
> message that didn't make it to the list, that a future version of the
> RFB protocol (4.0?) take some ideas from PPP, particularly in the area
> of negotiation. ...

Hi (and excuse my english please)!

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:

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

Now the server knows that the client supports encoding 255. But the
client doesn't still know wether the server will support that
message-type.
So if the server is able to handle ExtensionMessages it has to activate
this encoding. I think this could be done with such a message to the
client:

Type     Value
CARD8    255
CARD8    0
CARD16   10
CARD32   length( ext-data ), e.g. 17
CARD8[]  "available\n"
CARD8[]  comma separated list of supported extension types,
         e.g. "dragndrop,resize\n"

To let the server know which extensions the client supports the client
does also send such a message:

Type     Value
CARD8    255
CARD8    0
CARD16   10
CARD32   length( ext-data ), e.g. 7
CARD8[]  "available\n"
CARD8[]  comma separated list of supported extension types,
         e.g. "resize\n"

Now they could use the resize-Extension, however...
Any suggestions?

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