Want to help?

Want to help? - Project suggestions

One of the reasons we've made the source code available was so that people could modify and improve it, port it to new platforms, create new software using VNC, and so forth. Most of the contributions so far have been ports to new platforms; see the contribs page for details.

Here are some things that we think would be worth doing. If you would like to sign up to work on any of these, or if you have any new suggestions, please let us know. We'll start with the most important:

Improving WinVNC

If you've used both the X server (Xvnc) and the Windows server (WinVNC) you will notice that the Windows one is considerably slower. There is a simple reason for this. We have the source code for X, and we know exactly what it is doing. With Windows, we can get hints by inserting system hooks to monitor messages, but they're only hints and not all applications use suitable messages, so we often have to poll areas of the screen just to see if anything has changed. The two main alternative approaches would be:

writing a wrapper around the GDI DLLs which would hook into all screen updates at that level

Security

VNC uses a single TCP/IP connection, so a version which runs over Secure Sockets should be easy to build. Some users have reported that wrapping the connection using SSH works well and gives you compression as well. See the FAQ for details. But it would be nice to have it built-in, not least because SSH for Windows is not free.

People have built the viewer to allow access outward through SOCKS firewalls. See the contribs page.

Compression

The VNC protocol is fairly efficient in the way it transmits areas of the screen, but on slow networks a generic compression system would be worth incorporating. The important requirements are:

The compression code needs to be easily portable to all platforms including Java.

The code needs to be freely distributable under the GPL.

Single-application servers

A VNC server doesn't have to be a desktop. In many circumstances it can be useful for a single application to be a VNC server; we've done a CD player, for example, that can be controlled by anyone in the room. It would be good to have a simple toolkit to do this - perhaps the Java Swing toolkit could be extended so that the graphic context object used for drawing operations could be a VNC server as well...

Steve Cheng has written a GGI 'target' which allows programs using libGGI to become VNC servers - see the contribs page for details.

You can also get the source code for possibly the most basic VNC server we've written - rfbcounter.

Other platforms

One of our catch-phrases for VNC is "Any-to-Any"; the basic aim being to access any user interface from any other user interface. There are several platforms it would be good to support, but that we can't do here. We used to list several Unix platforms here but since the release of VNC others have ported it to HP-UX, SGI,. AIX, FreeBSD and SunOS 4 amongst others - see the contribs page for details.

How about a Windows 3.1 client? The current Win32 viewer is multi-threaded, but if that aspect were removed it shouldn't be too hard to build for 3.1.

If you have either a client or server running on any new platforms, we'd like to hear about it. Remember that you should be able to run a viewer on any platform which supports Java...

Record and Playback

Proxies which do things like recording a session for later playback, extra compression, scaling, access control, etc are not difficult to create, though you need to keep the latency low.

Other network transports

At the moment VNC uses TCP/IP for the connection between viewer and server, but that's purely for convenience. It could just as well run over Firewire, USB, RS232, modems and ISDN lines without IP being there at all. A modem link would be very handy particularly for remote maintenance; you could dial up PCs which did not necessarily have an IP address.

We don't, at present, support simple dialup without TCP, for example, because it involves writing a lot of code to talk to the modem, which would take more time than we have available at present, and would also expand dramatically the otherwise slim viewer and server. The right way to do this is probably to provide a scripting extension, so that the dialup code could be external and easily customised.

For comments, feedback, etc, please see the 'Keeping in touch' page.
Copyright 1999 - AT&T Laboratories Cambridge