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