Hi Jonathan, > Date: Sun, 13 Jan 2002 14:15:36 +0000 > From: Jonathan Morton <[EMAIL PROTECTED]> > Subject: Re: RFB Protocol > > >Does someone know, why RFB which is not fixed message size protocol (when it > >comes to screen updates) is not defined the Following way: > > > >[CARD32 MessageSize] > >[Message[MessageSize]] > > > >Why the protocol does not contain a Message Size field as the 1st member? > > Lack of foresight, probably. The original developers never realised > that future extensions might go beyond simple graphics encodings.
While that is certainly one possible explanation, there is actually a performance benefit to flushing partial screen updates to the network before the entire update has been processed. It causes the server CPU, network connection and viewer CPU to work in parallel, which helps lower the total response time. This precludes putting the size of the entire message in the message header. Of course, this can also be achieved by limiting the maximum size of the update region. However, it can be problematic to guess what size screen update will lead to a good buffer's worth of network traffic. In addition, it is even harder to guess what size screen update will use an appropriate amount of CPU time on the host before it makes sense to get the network subsystem and viewer CPU started. I'd prefer to see the message length included as well. However, I'm not quite ready to believe that the original designers completely ignored the concept of a packet length. -- Brian ---------------------------------------------------------------------------- TridiaVNC Pro: finally, affordable remote control. http://www.TridiaVNCPro.com/ --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------
