From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FexKL-0004zR-DV for qemu-devel@nongnu.org; Sat, 13 May 2006 12:50:49 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FexKJ-0004xr-L7 for qemu-devel@nongnu.org; Sat, 13 May 2006 12:50:48 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FexKJ-0004xn-En for qemu-devel@nongnu.org; Sat, 13 May 2006 12:50:47 -0400 Received: from [70.116.9.243] (helo=localhost.localdomain) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1FexMI-0007ek-Tf for qemu-devel@nongnu.org; Sat, 13 May 2006 12:52:51 -0400 Received: from [192.168.1.102] (helo=[192.168.1.102]) by localhost.localdomain with esmtp (Exim 4.52) id 1FexJw-0000Rt-0h for qemu-devel@nongnu.org; Sat, 13 May 2006 11:50:24 -0500 Message-ID: <44660E62.6050701@codemonkey.ws> Date: Sat, 13 May 2006 11:50:42 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc References: <28837826.1147436676713.JavaMail.root@eastrmwml07.mgt.cox.net> <446544E3.50208@codemonkey.ws> <200605131621.02743.paul@codesourcery.com> In-Reply-To: <200605131621.02743.paul@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Paul Brook wrote: > 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. > Exactly. If you have a good network connection, you'll tend to get lucky. The conditions for this race to happen are 1) a server receives a SetPixelFormat with a different BPP 2) the server has already sent data on the wire in the previous BPP but the client did not receive it before sending the SetPixelFormat message. Changing the BPP is rare. RealVNC does it because it attempts to be smart about reducing bandwidth (it drops down to 8bpp and then goes back up to 32bpp if the transfer rate is fast enough). The best way to avoid this behavior is to use AutoSelect=0 FullColor=1 on the vncviewer command line. Regards, Anthony Liguori > Paul > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel >