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.


Anthony Liguori


Qemu-devel mailing list

Qemu-devel mailing list

Reply via email to