Protocol Changes (was: Zoom / Scaling in VNC)

[Brandon Ibach]

Quoting John Wilson <tug "at" wilson.co.uk>:
> As far as I can tell (and I have written programs that process RFB data
> streams) you do not actually need message lengths. You *do* need a message
> to say how many bits per pixel it is using and there is a theoretical "race
> condition" which can arise in the current protocol. This can be fixed by
> utilising one of the padding bytes but nobody at AT&T seems very interested
> in fixing the problem (to be fair - none of the AT&T sourced software will
> hit the problem but attempts to generalise the protocol to
> broadcast/multicast will hit it)
> 
   No, you don't need a message length, if you're going to decode the
message (talking just about framebuffer updates here, as those are the
only variable-length message types, I believe), but you do if you just
want to read the entire message in, such as in the case of a proxy
that just passes the updates through without needing to decode and
reencode them. :)
   But, then, I could concede that having a message length could
create some overhead, as the server would have to calculate the entire
update, check the length, then send it out, rather than sending the
update out as it creates it.  I guess the question is whether this
creates unacceptable overhead.

-Brandon :)

---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------