VNC Possibilities

[Quentin Stafford-Fraser]

Simon - thanks for all your comments.  I think a device driver would be a
very good way of doing the Windows server; we talk about it a bit on the web
server.  We've even got some hardware which we think we could persuade to
resemble a VGA card to the PCI bus and yet produce VNC output.  The hardware
desciption of a VGA card is in some ways simpler than the software
description of a VGA driver, and it would work on any OS.  That's some way
down the line though :-)

>Protocol: Add an 'observer' mode .... uses ip multicast ( preserve
>bandwidth)  to display a desktop to multiple viewers. Good for training,
>and things like that..


Well, you know you can do this, though we don't use multicast?  You can have
multiple clients to one server easily: just request a shared session when
connecting.  The Windows server tends to slow down rather, but the X one can
handle quite a large number of connections without problems.  We've never
stress-tested it with more than about half a dozen clients - anyone want to
try?

>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.

Good idea, but the input is usually a very small amount of traffic compared
to display.

>The clients acknowledgement signal should also include the maximal
>transfer rate, so it only gets sent what it can handle...

Clients already only request what they can handle.  So you can have a slow
client on a modem on the other side of the world, and a fast client on a
local ATM network talking to the same server; one won't slow down the other.

>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.


We've considered this a bit; a remote audio buffer to match the current
concept of a remote framebuffer, and a very basic encoding from which client
and server could negotiate upwards.  But part of the reason the system works
so well is because we've been very strict that it was just a simple display
protocol.  We didn't want to recreate X.  It was with some hesitation that
we added ASCII cut & paste, and the bell facility.  If we did audio it would
be a separate channel and not part of this protocol.

Quentin