> Is the slowdown that results from SSH caused by 1) an increase in the amount > of data sent between the two endpoints of the secure tunnel or is the > slowdown caused by 2) just the additional computation necessary to encrypt > and decrypt the data stream?
Rather than ask the question like that, spin it around. Given a fixed bandwidth connection, is it possible that some protocol will not fit through the connection? The answer is always yes. As protocol overhead approaches channel bandwidth, what happens? The answer varies quite strongly on the combination of prototcols. Recall that for a dial-up connection, you are typically running IP on the raw layer, TCP on that, PPP on that, then perhaps a VPN on that, perhaps with SSL on that, then VNC on top, and finally the user is doing something. One keystroke or mouse movement results in a cascade of ever-expanding encapsulations. Think about running in 300 baud. Could the SSL ever get a complete ACK within its timer if there were a few dozen retries at the TCP level? No, not in any reasonable time. If all the protocols are stateless, response time can go to infinity, and everthing is still correct. For example, try runnig NFS over PPP on a noisy, slow line -- write speed of 1 byte per minute is perfectly valid. One "wild" idea I have is to run VNC on UDP (like FTP and NFS) instead of on TCP. Yes, this would be a major, perhaps impossible, change. For low bandwidth connections, it would be winner. --------------------------------------------------------------------- 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 ---------------------------------------------------------------------
