VNC Possibilities

[Simon Wittams]

VNC is a pretty cool app. 

I had some probs with the X version of vncviewer ( seg faults), 
but a quick recompile sorted that. I think it was libc6, or something.

I've been thinking about possible new features:

Windows server: this could probably be better done as a graphics 
adaptor. (Are the win32 graphics drivers integrated across NT &95 yet? I 
don't think so...)This either incorporates (as another thread) or 
communicates with a VNC server. It could also pass the GDI commands 
along to an existing graphics card driver. This could be selected in an 
additional tab on the display properties box. This fake driver would 
have to interrogate the real driver in the same way the Win32 GDI does 
at present, then pass the information back to the true GDI when it 
itself is interrogated for capabilities. The problem with this lies in 
the fact that the graphics card may interpret some random graphics call 
( e.g. Direct3d stuff) windows makes that the  VNC server can't. This 
could be handled in two ways : 1. Ignore capabilities of the card that 
the VNC server cannot handle - a bit annoying if you have some hugely 
powerful 3d accelerator 2. Allow the graphics card to draw the bit of 
the screen that it can handle, and steal it in the usual way - probably 
better...

and of course headless windows boxes could just have no graphics card 
selected in the new tab... though some machines need  one to boot...

Protocol: Add an 'observer' mode .... uses ip multicast ( preserve 
bandwidth)  to display a desktop to multiple viewers. Good for training, 
and things like that..
Have a distinct password for observers. The connection response from the  
server needs to be different, then if the client is 'observer aware' it 
can send an acknowledgement signal, and then not send any more signals 
of input to decrease traffic. If the client does not respond as observer 
aware, then ignore all input signals from it, and use unicast for it, to 
preserve backwards compatibility.
The clients acknowledgement signal should also include the maximal 
transfer rate, so it only gets sent what it can handle... would probably 
incur a performance penalty on the server, as it would have to handle 
more than one multicast group, maybe needing whole screen refreshes more 
often than with single bandwidth...

In the distant future: add 3d & sound encodings - in order to port the 
whole environment? Both are hard. How would you catch these events? For 
sound : maybe another fake driver in win32, and a rerouting /dev/audio | 
mixer | dsp in unix (or NAS).... hmmm. 

Robert Wittams