Old problem dredged up!
tjr "at" realvnc.com
Mon Nov 1 17:43:01 2004
The solution we adopted in version 4.0 was exactly as you describe - we
only ever have a single outstanding request and we delay pixel format
changes until that request has been satisfied. [Actually there's one
exception to this which is when the user explicitly refreshes the
screen, but I don't think that's the issue here]
All the posting references in your first mail are for earlier versions
of VNC which are known to have had the problem. Version 4.0 was
released in June this year and we've not had any other reports of
problems of this kind with it.
However the fact that you are seeing multiple requests sounds like there
must be a bug lurking somewhere. Can you tell us the exact version and
platform on which you are seeing this problem? Obviously any other
information which can help us track this down such as packet traces
would be useful - I suggest we take it off-line to avoid cluttering up
Mark Lentczner wrote:
> On Nov 1, 2004, at 2:23 AM, Tristan Richardson wrote:
>> You're right that this is a well-known issue. However there shouldn't
>> be a problem with any properly-conforming RFB implementations. If you
>> examine the code for the 4.0 viewers you will see that they only ever
>> change pixel format when there is no update request outstanding.
> Part of the point of the analysis was to show that there is no way that
> a viewer can know if there is no update request outstanding unless it
> only never sends a request until after it sees the update for a prior
> request. The 4.0 viewers do not do this. They can explicitly send two
> requests in a row. So when they see an update, they don't know if it is
> in response to the first request or to both. Hence, they can't know if
> it is "safe" to send a pixel format change.
> Alas, since an update can follow indefinitely after a request, if a
> viewer took the path of only sending a request after the update for a
> previous request -- that viewer would have to delay pixel format changes
> perhaps indefinitely. This would work, but would result in a poor user
> experience when using auto select to view servers that are primarily
> static: The initial view would be stuck at the old pixel format until
> there is a change on the screen... and then the whole screen would be
>> This means that the pixel format is known with certainty when an
>> update arrives [the viewer only ever sends one update request at a time].
> The part in brackets is not true with 4.0 viewers. I have packet traces
> that show explicit double requesting.
>> If you are seeing a problem when using a 4.0 viewer it is probably the
>> server not adhering to the RFB protocol spec - e.g. sending updates
>> when there is no update request outstanding.
> I see the problem with 4.0 viewer and OSXvnc. However, the crash is due
> to 4.0 viewer's double request. I'll write-up (and maybe draw) the
> packet trace in an e-mail later today.
> Several of the posting references in my first e-mail were to reports
> symptoms of the same problem between 4.0 viewers and servers. This
> issue isn't confined to OSXvnc server. It is inherent in the protocol.
> - Mark
> Mark Lentczner
> markl "at" glyphic.com
> VNC-List mailing list
> VNC-List "at" realvnc.com
> To remove yourself from the list visit: