This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: [PATCH] qemu vnc updates

To: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: [PATCH] qemu vnc updates
From: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Date: Tue, 26 Feb 2008 13:20:45 -0600
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Delivery-date: Tue, 26 Feb 2008 11:21:43 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <47C452BC.2030100@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <47C3F6FA.6080506@xxxxxxxxxxxxx> <47C43B37.1010209@xxxxxxxxxxxxx> <20080226162224.GI30568@xxxxxxxxxx> <47C43FA0.60808@xxxxxxxxxxxxx> <47C44C88.2010205@xxxxxxxxxxxxx> <47C452BC.2030100@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20080214)
Stefano Stabellini wrote:
Anthony Liguori wrote:
You mean realvnc? The race condition is due to it's use of SetPixelFormat. By slowing the updates, what you're really doing is just working around that race condition. That's not a proper solution though.

This goes away if you set the realvnc options so that it doesn't change the pixel format from what the server specifies.

I think that the realvnc "bug" is due to the fact that they assume that if they don't send any update requests, they shouldn't expect any. This is not a wrong assumption to make unless you are right about the 1 request -> N reply argument (I still think that this is not what the rfb spec says).

Regardless of whether you interpret the spec to allow 1 req -> N replies, the spec is clear that each multiple requests can result in a single reply. The requests/replies aren't sequenced though so you have no way of knowing what reply the request is in response too. For instance, consider the following:

Request  =>  Reply
Request  =>  Reply
Request  =>
Request  =>  Reply
Request  =>  Reply

This is entirely indistinguishable from:

Request  =>  Reply
Request  =>  Reply
Request  =>
Request  =>
Request  =>  Reply
               =>  Reply

Because the requests and replies don't carry any sort of sequence number.


Anthony Liguori

Besides my patch doesn't slow down the connection so much, I cannot tell the difference on a quick connections. I'll let you know what is the behaviour on a slow connection.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>