> > 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.
Swap IP for PPP. PPP runs on the raw layer, IP on top of that, any VPN goes here followed by another IP layer, TCP on top of that, SSL on that followed by VNC. Please, don't mangle the OSI stack any more than BSD already has. >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. Only if the line is *extremely* bad. You're talking pathelogical conditions which no sane user would even attempt to run graphical, interactive applications over. And yes, NFS is designed to work with unreliable links, and will tend to do the Right Thing when things go wrong - it's not expected to perform well in those circumstances. >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. FTP does not run on UDP. I don't think NFS does either. You forget that UDP stands for Unreliable Datagram Protocol, and RFB *requires* reliable transport. If you look closely at the RFB specification, you will notice that there is no defined way to locate the beginning of a message, unless you can follow the entire stream up to that point (you can guess, but that is also unreliable). The messages can be (and usually are) bigger than any UDP packet, so you can't use a packet boundary as a marker. Additionally, the whole premise is based on the server knowing which parts of the screen have arrived at the client, or are at least on their way - again, only possible with a reliable transport such as TCP. If your packet loss was high enough for UDP to be a significant performance gain, the end user would only see bits of the screen, or you'd have to send so much redundant data that it'd be a net loss. TCP will, in general, only retransmit packets that have actually been lost in transit, and is thus extremely efficient as a reliable stream transport. To overcome the difficulties in the previous two paragraphs, you'd practically have to re-implement TCP. Reinventing the wheel is a Bad Thing. Also, it'd make you incompatible with existing VNC implementations, which is highly unlikely to win you many supporters. -- -------------------------------------------------------------- from: Jonathan "Chromatix" Morton mail: [EMAIL PROTECTED] (not for attachments) website: http://www.chromatix.uklinux.net/vnc/ geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*) tagline: The key to knowledge is not to rely on people to teach you it. --------------------------------------------------------------------- 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 ---------------------------------------------------------------------
