On 2/11/11 3:20 AM, Pierre Ossman wrote: >> As Cendio is >> proposing to move to a unified cross-platform viewer code, I even wonder >> whether we shouldn't split viewer and server into separate builds. How >> much of the code will really be shared by both once the viewer is using >> FLTK? >> > > common/, which is quite a bit. But there might be some idea to see > things as four subprojects; librfb, vncviewer, winvnc and Xvnc. They > are interconnected enough to continue seeing them as parts of a larger > project though. VNC is still a protocol in need of more improvement, > and we can achieve that more easily if we keep the clients and servers > close.
I guess my basic concern is that the GnuTLS feature highlighted the fact that we are designing from the bottom up rather than the top down. I don't know of any other projects that try to support this many different permutations with only three main developers. I just feel like we are all trying to build and use the code in fundamentally different ways, so there are few cross-checks, and it's easy for a patch to break something unrelated. I have a great number of ideas regarding how to improve the protocol as well, which would likely be a topic for another lengthy e-mail, but I'll give you the brief version here. One of the fundamental performance problems that 3D/video users have discovered with VNC is that it is a client-driven protocol, and thus it requires a round trip between client and server for every frame sent. That means that it can never achieve more than 1 / (ping time) frames/second. As long-haul fibre networks become more common, and satellites become faster, this issue has come to the forefront, because it is no longer the bandwidth that is limiting the frame rate of VNC-- it's the latency. The whole client-driven scheme was necessary to avoid a multi-threaded server, which was necessary because threads weren't ubiquitous on Unix machines in the 1990's, nor was there enough memory to use a separate image queue for each client. If we were inventing VNC today, however, we'd probably use a separate thread and image queue per client and implement a frame spoiling mechanism to allow multiple simultaneous clients to be driven at different frame rates. In the evolving TurboVNC code base, I took advantage of the RFB Continuous Updates extension to implement a "server push" option for high-latency situations, but it's admittedly a bit of an esoteric feature. Most users aren't going to know under what situations it should be enabled/disabled, and it also breaks collaboration to a certain extent (since the image queue is still single-threaded, all of the collaborators are locked into the same frame rate whenever CU is enabled.) It's also necessary for the server to employ certain heuristics for the feature's use, because without frame spoiling/coalescing, if it sent every single update directly to the client, it would create too much chatter. What I really want out of a next-gen protocol: (1) No per-frame client-server round trips, which means it needs to be a server push, not a client pull, protocol. The client still has to have the ability to pull updates from the server, because only the client knows when an area of its window needs refreshing, but the server should be driving the train most of the time. (2) The ability to drive different clients at different frame rates (a per-client image queue with frame spoiling accomplishes this.) RFB Continuous Updates solves (1) but not (2). (2) would require a fundamental re-architecture of Xvnc. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
