Re: Re: [PATCH] qemu vnc updates

[Anthony Liguori <anthony@codemonkey.ws>]

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.