From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S75w5-0001Cz-2j for qemu-devel@nongnu.org; Mon, 12 Mar 2012 10:09:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S75vy-0007E9-Jn for qemu-devel@nongnu.org; Mon, 12 Mar 2012 10:09:16 -0400 Received: from mx1.redhat.com ([209.132.183.28]:30363) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S75vy-0007Da-9e for qemu-devel@nongnu.org; Mon, 12 Mar 2012 10:09:10 -0400 Message-ID: <4F5DEFBF.8090902@redhat.com> Date: Mon, 12 Mar 2012 13:44:47 +0100 From: Gerd Hoffmann MIME-Version: 1.0 References: <4F5CB429.4000907@codemonkey.ws> <20120311152528.GD7273@garlic.redhat.com> <4F5CC692.7050002@codemonkey.ws> <4F5DAC69.6010002@redhat.com> <4F5DB906.2030508@redhat.com> <4F5DC604.9010702@redhat.com> <20120312100307.GD6256@garlic> <4F5DCF6A.60008@redhat.com> <20120312112910.GG6256@garlic> <4F5DDF52.6040503@redhat.com> <20120312114548.GI6256@garlic> In-Reply-To: <20120312114548.GI6256@garlic> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Spice-devel] seamless migration with spice List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede , "spice-devel@freedesktop.org" , qemu-devel , Anthony Liguori On 03/12/12 12:45, Alon Levy wrote: > On Mon, Mar 12, 2012 at 12:34:42PM +0100, Gerd Hoffmann wrote: >> On 03/12/12 12:29, Alon Levy wrote: >>> >>> Actually the agent protocol does extend nicely to multiple clients - I >>> forgot the name but there is an additional wrapper between the >>> client/server originating message and the guest received message, that >>> is currently used for server or client originating messages, and can be >>> reused to have multiple in flight different client messages. >> >> I think you'll have issues in the layer above though. Two spice clients >> doing cut+paste operations at the same time? Two spice clients >> requesting different screen resolutions? > > Yeah, you're right of course, this needs to be dealt with somehow. > cut+paste: maps nicely to a number of different buffers. Would need > some policy, and the session agent becomes closer to a buffer manager. > resolutions: again policy, perhaps have a master client, or if none > defined let the last or just the first choose. Not sure. > > But these issues don't need to be solved now, do they? Surely not. But better keep it in mind when figuring how to handle migration, so we are prepared to xfer all needed state in case we implement that some day. How does multi-client handle this today? cheers, Gerd