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