In the fictitious RFB 4.0 that I'm working on: http://www.evilsecurity.com/vnc/
message length and smaller packets are both there. Sometime soon, I've rev the protocol draft to include an excellent suggestion to use secsh as the transport, and use RFB on top of that. Andrew -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of W. Brian Blevins Sent: Tuesday, 15 January 2002 2:29 AM To: ATT Email List Subject: Re: RFB Protocol 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. ... 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. --------------------------------------------------------------------- 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 ---------------------------------------------------------------------
