Mailing List Archive: VNC: list

VNC Possibilities

Index | Next | Previous | View Threaded

swittams at cix

Feb 25, 1998, 3:53 PM

Post #1 of 6 (617 views)
Permalink

VNC Possibilities

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

quentin at orl

Feb 25, 1998, 4:41 PM

Post #2 of 6 (607 views)
Permalink

Re: VNC Possibilities [In reply to]

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

alan at cymru

Feb 26, 1998, 1:52 AM

Post #3 of 6 (629 views)
Permalink

Re: VNC Possibilities [In reply to]

swittams at cix

Feb 26, 1998, 5:26 AM

Post #4 of 6 (605 views)
Permalink

Re: VNC Possibilities [In reply to]

Thanks for the swift... btw its Robert, I'm just using my brothers account :)

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

Bit expensive for freeware :) but good for headless boxes... but it would be
hard to have a displaying and vnc-serving card without limiting the choice
of features.

> 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?
I forgot to mention the observers shouldn't be able to do anything :). Can
shared connections actually do anything?

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

Ahh, I see... I meant that if you use multicast for the observer mode, have
different multicast groups for different bandwidths... in order to reduce the
load on the server but not slow down the clients with too much data.

> If we did audio it would
> be a separate channel and not part of this protocol.

Hopefully with some kind of synchronisation... for slow clients with many
possible routes.

Rob

jnw at orl

Feb 26, 1998, 6:24 AM

Post #5 of 6 (610 views)
Permalink

Re: VNC Possibilities [In reply to]

On Thu, 26 Feb 1998, Simon Wittams wrote:

[snip]
[Text regarding shared displays on the VNC system]

> I forgot to mention the observers shouldn't be able to do anything :). Can
> shared connections actually do anything?

For WinVNC:
There is a tick-box on the properties panel to stop new connections from
being able to manipulate the display. This _only_ affects new
connections, not current ones at the time the change is made. Take care
not to set the option remotely and then disconnect!

Cheers,

James "Wez" Weatherall
--
Olivetti & Oracle Research Laboratory, Cambridge, UK.
Tel : Work - 343000

quillan at doitnow

Feb 26, 1998, 9:23 AM

Post #6 of 6 (597 views)
Permalink

Re: VNC Possibilities [In reply to]

Simon Wittams wrote:
>
> Thanks for the swift... btw its Robert, I'm just using my brothers account :)
>
> >
> > 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.
>
> Bit expensive for freeware :) but good for headless boxes... but it would be
> hard to have a displaying and vnc-serving card without limiting the choice

> > >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.
>
> Ahh, I see... I meant that if you use multicast for the observer mode, have
> different multicast groups for different bandwidths... in order to reduce the
> load on the server but not slow down the clients with too much data.

I haven't look at the protocall at all yet, but I was wondering if it
would be
possible to have some sort of redirection server that would connect to
one
server and serve many clients. This would keep the load off of the main
server
and distribute it to where it is needed. you could create a topology as
follows.

-Viewer
/
MainServer -
\ - Viewer
\ /
- ViewRedirector ---- Viewer
\
- Viewer

>
> > If we did audio it would
> > be a separate channel and not part of this protocol.
>
> Hopefully with some kind of synchronisation... for slow clients with many
> possible routes.
>
> Rob

The above redictor combined with some sort of audio streaming would
be great for distributed classrooms on the internet. I was looking at
Spead Freely 6.1c at http://www.fourmilab.ch/speakfree/unix/ .
It also runs on both Windows an Unix, and is in the public domain. I
am currently having problems because there is no place to do demo's at
work big enough to hold more than a coulpe of people. With this I can
at least get a few monitors going so people don't have to crowd.

John C. Quillan

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads