> >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.
Very early on you catch that I was working without proper references at hand! > >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. Here I must strongly disagree. The notion of a GUI as an independent entity is outside the knowledge of most computer users today. The average computer user, perhaps even up to 95%, expect either a GUI or nothing. The notion that valid work can be done without a GUI, or the even more radical idea that a GUI can impede productivity, has nearly disappeared in practice. "no sane user" describes most users today. This is a really sad state of affairs, but is exactly why people struggle to use something like VNC. The GUI is required, no matter how slow. No where near "the right thing", but common. > >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 Here we get into good discussion. FTP does not run on UDP. I was hasty and wrong. FTP requires a reliable connection for the control circuit -- look at RFC 959. As for the data circuit, things are not so clear. FTP relies on TCP to perform reliable transport. But the RFC even states (section 3.4, I think) that FTP data transport is not inhernetly reliable. > that UDP stands for Unreliable Datagram Protocol, and RFB *requires* Not to be picky, but UDP's specification, RFC 768, uses the term "User Datagram Protocol". You are correct in spirit. > 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. 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. Packet loss is not the only issue, but the overhead of the protocol itself, in bits per unit time, is a problem. No doubt you have been following the devlopment of IP6; one of the major arguments was over the size of the address field. In great detail the issue was argued. IP6 will make the problem of protocol overhead worse for low bandwidth channels -- everybody agreed. But the committee went ahead and made the address larger. Although I agree TCP/IP is a reliable protocol, I disagree it is efficient. In fact I have never seen it described as efficient anyplace else. My main point is there is room to make VNC, or perhaps something like VNC, perform much better at the low end. Perhaps the FTP model would work, splitting the data and control streams. 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. As computer scientists we like to pin down a solution and make it work. That has been done with VNC. Something like VNC/RFB can be made to work really well on low speed connections, but we are not there yet. Perhaps giving up on "the whole premise" will make for a more useable product in the real world. If I had nothing else to do with my time, I would investigate this question in great detail. --------------------------------------------------------------------- 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 ---------------------------------------------------------------------
