From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MM8Zu-0000lZ-KI for qemu-devel@nongnu.org; Wed, 01 Jul 2009 18:46:58 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MM8Zq-0000l5-4D for qemu-devel@nongnu.org; Wed, 01 Jul 2009 18:46:58 -0400 Received: from [199.232.76.173] (port=40873 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MM8Zp-0000kf-T9 for qemu-devel@nongnu.org; Wed, 01 Jul 2009 18:46:53 -0400 Received: from mx2.redhat.com ([66.187.237.31]:57261) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MM8Zp-00072G-EJ for qemu-devel@nongnu.org; Wed, 01 Jul 2009 18:46:53 -0400 Message-ID: <4A4BE743.1090007@redhat.com> Date: Thu, 02 Jul 2009 00:46:27 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/2] Tunnel character device data over VNC (v1) References: <20090701162114.GB24296@redhat.com> <4A4B91F7.9010206@redhat.com> <20090701165039.GF24296@redhat.com> <4A4B9D2F.5000607@redhat.com> <4A4BB038.7050401@codemonkey.ws> <4A4BBBE6.2070601@redhat.com> <4A4BC01B.7000100@codemonkey.ws> <4A4BCD80.2000906@redhat.com> <4A4BD5EB.5060701@codemonkey.ws> In-Reply-To: <4A4BD5EB.5060701@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On 07/01/09 23:32, Anthony Liguori wrote: > Gerd Hoffmann wrote: > >> With multiple connections and multiplexing: You'll just connect, type >> a few commands, disconnect, done. You'll even see what you have done >> when you come back to the office the next day. >> >> Also note that the vnc server accepts input from multiple clients as >> well, which can lead to simliar problems. Nobody wants to kill support >> for multiple clients just because of that, because in practice it >> isn't a issue. > > I don't disagree with your use-case. What I'm pointing out, is that we > need to do some major surgery to get there. I didn't say it is easy ;) But I want to make sure we don't miss the big picture when we start multiplexing for vnc, so others can join the party. > [ flow control issues ] Tricky indeed. I think Dan's current patches don't care about flow control at all. > I agree that mirroring is a pretty reasonable policy to map a single I/O > source to multiple clients for some devices. That should be a front-end > decision though. Dan's patches can do mirroring only. I *think* one could build a tcp backend based on Dan's patches which can handle multiple connections at the same time. It would basically do the same vnc data streams do: Listen for connects, when a new connection comes in create a new CharCaptureState instance and link it up. When the connection drops teardown. > In this model, I still don't see having two different back-ends > connected to a single front-end. The frontend shouldn't have to care at all about who owns the CharCaptureState instances it feeds. > I don't know if I agree there's a whole > lot of value in that Having a file backend writing logs and some other backend for interactive work is a very reasonable thing IMHO. cheers, Gerd