From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NKCfm-0005kB-22 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 10:17:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NKCfh-0005hZ-40 for qemu-devel@nongnu.org; Mon, 14 Dec 2009 10:17:17 -0500 Received: from [199.232.76.173] (port=46810 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NKCfg-0005hL-PX for qemu-devel@nongnu.org; Mon, 14 Dec 2009 10:17:12 -0500 Received: from mx1.redhat.com ([209.132.183.28]:62151) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NKCfg-0001GD-AX for qemu-devel@nongnu.org; Mon, 14 Dec 2009 10:17:12 -0500 Date: Mon, 14 Dec 2009 15:17:07 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] Re: Spice project is now open Message-ID: <20091214151705.GH23733@redhat.com> References: <4B231182.1080208@codemonkey.ws> <20091212144433.GA26966@random.random> <4B23B0BE.7080408@codemonkey.ws> <20091212160626.GB26966@random.random> <4B23D585.70400@codemonkey.ws> <4B241A99.2000704@redhat.com> <4B242B40.4050409@codemonkey.ws> <4B24C5EF.2090607@redhat.com> <4B264EC4.7020500@codemonkey.ws> <4B265153.3050705@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B265153.3050705@redhat.com> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Andrea Arcangeli , Paolo Bonzini , dlaor@redhat.com, qemu-devel@nongnu.org On Mon, Dec 14, 2009 at 04:53:07PM +0200, Avi Kivity wrote: > On 12/14/2009 04:42 PM, Anthony Liguori wrote: > >I think it's a bit trickier though because ideally you would want to > >use the vnc protocol to negotiate which vm you're connecting to. > > Right, of course. If the client can no longer choose the target using > its port number, it has to select it in some other way. > > >That implies that you actually need to hand over the fd in a setup > >state. It's complicated by any encryption protocol too. > > Yes - need to pass the encryption state. Hopefully the crypto stacks > support this. There's no mechanism for this in the SASL libraries. With GNUTLS there is the ability to preserve negotiated session state from one TLS conenection and used it upon opening the next connection to fast-track the handshake phase. This doesn't allow you to pass the state for an existing connection to a new process though and have it carry on Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|