From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NUHmh-0007wW-7f for qemu-devel@nongnu.org; Mon, 11 Jan 2010 05:46:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NUHmc-0007v6-Kp for qemu-devel@nongnu.org; Mon, 11 Jan 2010 05:46:06 -0500 Received: from [199.232.76.173] (port=55728 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NUHmc-0007v2-GM for qemu-devel@nongnu.org; Mon, 11 Jan 2010 05:46:02 -0500 Received: from mail2.shareable.org ([80.68.89.115]:39192) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NUHmb-0002lv-Uo for qemu-devel@nongnu.org; Mon, 11 Jan 2010 05:46:02 -0500 Date: Mon, 11 Jan 2010 10:45:53 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH 5/8] virtio-serial-bus: Add support for buffering guest output, throttling guests Message-ID: <20100111104553.GA4746@shareable.org> References: <1262849506-27132-6-git-send-email-amit.shah@redhat.com> <20100108011231.GA5011@shareable.org> <20100108050351.GB8999@amit-x200.redhat.com> <20100108133503.GA19328@shareable.org> <20100111083443.GA6061@amit-x200.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100111083443.GA6061@amit-x200.redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Amit Shah Cc: qemu-devel@nongnu.org Amit Shah wrote: > On (Fri) Jan 08 2010 [13:35:03], Jamie Lokier wrote: > > Since VNC is clearly designed to work over TCP, and is written by > > people who know this, I'm wondering why you think it needs to be > > different for virtio-serial. > > For vnc putting stuff from a guest clipboard into vnc client clipboard > using the ServerCutText command, the entire buffer has to be provided > after sending the command and the 'length' values. Are you talking about a VNC protocol command between qemu's VNC server and the user's VNC client, or a private protocol between the guest and qemu's VNC server? > In this case, if the data from guest arrives in multiple packets, we > really don't want to call into the write function multiple times. A > single clipboard entry has to be created in the client with the entire > contents, so a single write operation has to be invoked. Same question again: *Why do you think the VNC server (in qemu) needs to see the entire clipboard in a aingle write from the guest?* You have already told it the total length to expect. There is no ambiguity about where it ends. There is no need to do any more, if the reciever (in qemu) is implemented correctly with a sane protocol. That's assuming the guest sends to qemu's VNC server which then sends it to the user's VNC client. > For this to happen, there has to be some indication from the guest as to > how much data was written in one write() operation, which will let us > make a single write operation to the vnc client. When it is sent to the user's VNC client, it will be split into multiple packets by TCP. You *can't* send a single large write over TCP without getting it split at arbitrary places. It's *impossible*. TCP doesn't support that. It will split and merge your writes arbitrarily. So the only interesting part is how it's transmitted from the guest to qemu's VNC server first. Do you get to design that protocol yourself? -- Jamie