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] _______________________________________________ VNC-List mailing list [EMAIL PROTECTED] To remove yourself from the list visit: http://www.realvnc.com/mailman/listinfo/vnc-list
