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

["Daniel P. Berrange" <berrange redhat com>]

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

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|