Re: [gtk-vnc-devel] Supporting VMware VNC extensions in gtk-vnc

[Dustin Byford <dbyford vmware com>]

On Tue Jan 08 22:04, Daniel P. Berrange wrote:
> On Tue, Jan 08, 2008 at 01:12:49PM -0800, Dustin Byford wrote:
> > On Fri Jan 04 20:53, Ramesh Dharan wrote:
> > > > As Ramesh points out, I'll be working on a way to
> > > > negotiate client->server message capabilities reasonably soon.  With
> > > > that, I hope to have more formal documentation as well.
> > > 
> > > Just so we're all on the same page: there *is* an acceptable way to negotiate new client->server messages, which Anthony previously outlined for me. I don't believe it's spelled out in exact detail in the latest RFB protocol document, but it works as follows:
> > > 
> > > - client reports that it supports the new message type using an encoding number in the set of encodings it sends to the server
> > > - server sends a dummy 'ack' rectangle back using that encoding number to confirm that the server supports it
> > > - client starts sending messages using the new message type as it desires
> > 
> > Sure, but like our "custom" multiplexing of VMWMessages, we'll probably
> > want a way to figure out which sub-messages (VMWKey/VMWPointer/[new
> > stuff]) the server can support.  I guess we could burn a rectangle
> > encoding for each one, but that seems like a waste.  It might just be as
> > simple as making that "ack rectangle" contain a list of supported
> > sub-message IDs.
> 
> Rather than overloading meaning of the payload in the psuedo-encoding
> still further it might be better to define one of the sub-message of
> your VMWMessage as a feature negotiation message right from the start.
> That way your protocol has built-in extensability. This is the approach
> taken by existing extensions such as "Tight" and "VeNCrypt" - they
> use a psuedo-encoding / auth type message to turn-on/detect presence
> of the extension. From that point they use their own defined sub-messags
> to negotiate various aspects of their protocol extension

That seems reasonable, thanks for the suggestion.

                --Dustin