Virtual Network Computing
from ORL

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 pseudo-video driver, which could notify WinVNC with more precise details

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

3-button mouse emulation in Windows

Some PC X servers have an option for users with 2-button mice, where pressing both buttons at once counts as a middle-button press.  This really needs to be implemented in the Windows viewer. It's not difficult, but it needs thinking through carefully.   Volunteers to write the code welcome!

Whenever you get any mouse click you must not send it at once, but instead set a timer for a small amount of time. If the other button is pressed before the timer goes off, you then send a middle button press and cancel the timer. If the timer goes off, you send the original button press. You need to record the fact that you've done this, so that when either (or both?) are released, you send a middle-button-up in place of the actual event, and ignore the event from the other button. Other events from the mouse might also require the timer to be cancelled. Quick double clicks add complications. And do you insist the both buttons must be pressed at the same coordinates, perhaps with a small margin of error? And if not, at which coordinates do you count the click to have occurred? And if shift is pressed during one click but not during the other, what is this?

Very thin clients

It's a bit silly to have to run a whole X server or Windows session just to run a viewer for a remote VNC server.  It should be straightforward to write a very thin client which talks directly to the graphics system of the machine, and so requires much less in the way of resources.  The chief example of this is the SVGALIB viewer based on the single-floppy linux distribution - see the contribs page - but a similar approach based on DOS or QNX would also be good.

Talking of older machines, how about a Windows 3.1 client?  You can use 3.1 machines by installing a browser and using Java (we recommend IE4), but it tends to be very slow.  The current Win32 viewer is multi-threaded, but if that aspect were removed it shouldn't be too hard to build for 3.1.

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:

• It should be possible to switch it off, so that it doesn't increase latency on fast networks.  This would probably mean adding an extra message to the VNC protocol.

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

• The code needs to be freely distributable under the GPL.

Mac viewer and server

We are planning a Mac viewer in the not-too-distant future, and we plan to investigate the feasibility of a Mac server.   If anyone gets there before us, we'd be only too grateful! On recent Macs the Java implementation supplied with Internet Explorer 4 works really quite well.

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.

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.

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 1998 - The Olivetti & Oracle Research Lab