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 resent.
> 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
http://www.ozonehouse.com/mark/
[EMAIL PROTECTED]
[demime 1.01d removed an attachment of type application/pkcs7-signature which had a
name of smime.p7s]
_______________________________________________
VNC-List mailing list
[EMAIL PROTECTED]
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list
