From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FevvY-00067Y-LV for qemu-devel@nongnu.org; Sat, 13 May 2006 11:21:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FevvX-00067L-Ls for qemu-devel@nongnu.org; Sat, 13 May 2006 11:21:08 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FevvX-00067I-HE for qemu-devel@nongnu.org; Sat, 13 May 2006 11:21:07 -0400 Received: from [65.74.133.6] (helo=mail.codesourcery.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FevxW-0000Mr-K3 for qemu-devel@nongnu.org; Sat, 13 May 2006 11:23:10 -0400 From: Paul Brook Subject: Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc Date: Sat, 13 May 2006 16:21:01 +0100 References: <28837826.1147436676713.JavaMail.root@eastrmwml07.mgt.cox.net> <446544E3.50208@codemonkey.ws> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605131621.02743.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Saturday 13 May 2006 16:15, Chris Wilson wrote: > Hi Anthony, > > On Fri, 12 May 2006, Anthony Liguori wrote: > > A problem arises when the client sends a SetPixelFormat message. There > > is no "ack" message from the server so the client has to assume that as > > soon as it sends out the message, the server is now using the new pixel > > format. RealVNC uses totally synchronous IO routines so in practice, the > > window for this race condition is small for them. It definitely can > > occur though and I've reproduced it with a normal VNC server. > > > > Since the QEmu VNC code is completely asynchronous, we have a much larger > > window where this race can occur. The easiest thing to do is avoid the > > race all together and not have your client use SetPixelFormat frequently. > > Please forgive my ignorance, but why is there a race condition here? You > have exactly one socket open between client and server. It's a TCP socket > so out-of-order delivery or missing messages is impossible. Yes, but it's a bidirectional connection. The client doesn't know if the packet it just received was send before or after the server received the SetPixelFormat message. Paul