From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: Re: [PATCH] qemu vnc updates Date: Tue, 26 Feb 2008 13:20:45 -0600 Message-ID: <47C4668D.1040509@codemonkey.ws> References: <47C3F6FA.6080506@eu.citrix.com> <47C43B37.1010209@codemonkey.ws> <20080226162224.GI30568@redhat.com> <47C43FA0.60808@eu.citrix.com> <47C44C88.2010205@codemonkey.ws> <47C452BC.2030100@eu.citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <47C452BC.2030100@eu.citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Stefano Stabellini Cc: xen-devel@lists.xensource.com, "Daniel P. Berrange" List-Id: xen-devel@lists.xenproject.org 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.