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

[Anthony Liguori <anthony@xxxxxxxxxxxxx>]

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.

Regards,

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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel