Re: [Qemu-devel] Re: Spice project is now open

[Mark McLoughlin <markmc@redhat.com>]

On Mon, 2009-12-14 at 15:10 +0000, Daniel P. Berrange wrote:

> The model I had in mind was for the proxy to define a VNC extension that
> allows the client to query what 'desktops' are available and request
> switching between them at any time. The list of desktop would of course
> be authorized per client, and strong authentication is a must for this.
> 
> Any time a switch was made, the RFB protocol would return to the 
> 'ServerInit' state. The idea is that you should not assume a homogenous 
> environment, and you really don't want to fall down to the lowest common
> denominator of extensions, nor have the proxy doing re-encoding on the FB
> data updates. Returning to the ServerInit state allowing the client to
> re-negotiate the set of encodings for the new desktop, and so the proxy 
> can be fairly stateless and while needing to understand the wire protocol,
> it can just pass through the actual FB update data unchanged.
> 
> The combo of the an extension for switching desktops on the fly and the
> encryption state problem doesn't really seem to fit with passing the VNC
> FD over with SCM_RIGHTS.

I actually did a demo of this before, in a slightly different context.

The idea was:

  - vnc client connects to gdm, which spawned a Xvnc(A) server with a
    gdm auth dialog

  - user logs in and if you've an Xvnc server already, it would move 
    the client connection to the original Xvnc(B) server

  - first, gdm would tell the (A) to sync it's state; (A) would stop 
    sending updates, flush its zlib/tls streams and pass gdm the
    current state of the connection - e.g. the protocol version, pixel 
    format, supported encodings etc.

  - then gdm would pass the connection fd using SCM_RIGHTS to the 
    existing Xvnc along with the connection state, and (B) would pick
    up the connection

  - from the users point of view, they were logged instantly back into 
    their old session

Simply flushing the encryption/compression state was the key, but AFAIR
clients needed a trivial fix to allow them to properly handle the server
flushing the stream. The alternative was to somehow get the server to
dump its encryption/compression state and pass that to the existing
server, but that seemed quite difficult when I looked.

SCM_RIGHTS rule ... this was definitely one of the most fun hacks I've
done :-)

Cheers,
Mark.

p.s. - I'm sure I can dig up the code, here are some diffs that look
like older than what I remember finishing:

  http://www.gnome.org/~markmc/code/gdm-vnc-support.patch
  http://www.gnome.org/~markmc/code/test-gnutls-client-close-restart.c
  http://www.gnome.org/~markmc/code/test-gnutls-server-close-restart.c
  http://www.gnome.org/~markmc/code/test-zlib.c
  http://www.gnome.org/~markmc/code/vnc-4.0b5-vncviewer-tls.diff
  http://www.gnome.org/~markmc/code/vnc-managed.patch
  http://www.gnome.org/~markmc/code/vnc-tls.patch