From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: QEMU 0.8.1 and vnc
Date: Sat, 13 May 2006 11:50:42 -0500 [thread overview]
Message-ID: <44660E62.6050701@codemonkey.ws> (raw)
In-Reply-To: <200605131621.02743.paul@codesourcery.com>
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
>
next prev parent reply other threads:[~2006-05-13 16:50 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-12 12:24 [Qemu-devel] Re: QEMU 0.8.1 and vnc Ben Taylor
2006-05-13 2:30 ` Anthony Liguori
2006-05-13 15:15 ` Chris Wilson
2006-05-13 15:21 ` Paul Brook
2006-05-13 16:50 ` Anthony Liguori [this message]
2006-05-13 19:17 ` Jamie Lokier
-- strict thread matches above, loose matches on Subject: below --
2006-05-05 12:24 [Qemu-devel] " Ben Taylor
2006-05-05 14:06 ` [Qemu-devel] " Anthony Liguori
2006-05-12 3:58 ` Troy Benjegerdes
2006-05-12 11:02 ` andrzej zaborowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44660E62.6050701@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).