-----Original Message----- > From: Frank Evan Perdicaro [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 09, 2001 1:55 PM > To: [EMAIL PROTECTED] > Subject: Re: vnc-list-digest V1 #1332
> Given that it might be possible to force RFB packets to fit into UDP > packets, do you have any actual data (studies, source code to do tests, > etc.) on the unreliability of UDP packets delivered on low-speed > dial-up connections that we are considering? Although I have no > scientific studies, my experience is UDP is 99% reliable on 24K dial-up > connetions. This might be true if you're directly dialed into the network you're working on. Anecdotally, when working over the Internet I've often seen dropped packet rates of 10% or 15% on UDP RealVideo streams, with bursts much higher. While most of the time 99% of your packets will probably get through, you have *no* guarantee of this, and you have no way of knowing how many of them (or if any of them at all) have gotten through. TCP connections are also easier to tunnel through firewalls. > As for the idea that the whole screen needs to be tracked perfectly, at > some level of spacial, temporal, or color fidelity in order for any > useful work to be done, I disagree. This is not how the eye works, > and this is not how the brain works, and it is not how the real world > works. I just don't buy this. If whole packets of the display are missing, you're going to end up with big chunks of pixels that are gone...you'll get a checkerboard effect that will force the user to do a full screen refresh, at a much higher bandwidth cost than just getting the whole thing in TCP to begin with. It will be flakey and unreliable, and will look "buggy". No, TCP isn't as efficient as UDP, but by the time you duplicate the connection-handling and error checking features of it with UDP, you're not going to end up with anything better. --------------------------------------------------------------------- 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 ---------------------------------------------------------------------
