RFB Protocol

Andrew van der Stock ajv "at" greebo.net
Mon, 14 Jan 2002 23:48:02 +0000


I mention scaling in the introduction of the document. Just not directly
implemented into the draft as yet. I hope that server-side scaling, once
implemented in the draft protocol, will allow more widespread adoption of
this handy feature. Antialiasing could be done by the server, but I think
that it might be better done on the client. However, I'll include
orthagonality in the protocol if PalmVNC doesn't already include it.

It's up to the server and client to work with the platform's sound managers
/ drivers - the protocol is neutral about how you got the sound and what you
do with it once you have it - it just provides the transport for a
frequently requested feature. Obviously, if the client doesn't implement
digital sound playback or recording (my Palm m100 for example has basic
sound capabilities, similar to that of a Commodore 64), they can choose not
to open the sound channel.

The client tells the server about its tile cache during "discovery" using
the configuration channel (the only channel that must exist). See section 9
of the current draft. When things change, like display resolution, or the
keyboard disappears (USB land), the configuration channel can apply that
change on the fly.

For the extremely thin clients, the minimum functionality for a 4.x client
is actually less than a 3.x client as you can negotiate not to take all but
one channel (the configuration channel). Indeed, you could choose to
implement just one tile decoder, and it should still work as long as the
server has that encoder. This more than offsets the possibly increased
complexity of the required minimum authentication (SRP).

I'll note now that SRP can be slow on really slow platforms. A 16 MHz Palm
will probably take up to 2 seconds to do the math required for a single
authentication.

Extensible channels are possible on top of the default ones, thus preventing
incompatible protocols. Companies like Tridia can implement Tridia specific
channels, but still allow non-Tridia clients to connect or vice versa. A
client can open (or not open) as many channels as the server supports.

Thanks for the feedback.

Andrew

----- Original Message -----
From: "Wayne Throop" <throopw "at" sheol.org>
To: <vnc-list "at" uk.research.att.com>
Cc: <throopw "at" sheol.org>; <ajv "at" greebo.net>
Sent: Monday, January 14, 2002 6:21 PM
Subject: Re: RFB Protocol

> No scaling?
> Are there implementations for sound on linux, unix, and windows?
>
> I hope that the client is able to tell the server the size of
> the tile cache, so that "not in cache" replies are kept to a minimum.
>
> I also hope that a client can remain very, very thin,
> and ignore things like fonts, windows, strings, and other new
> high-level constructs, and just bang out the pixels.
>
> And wrt a client remaining thin, scaling as a server-side thing,
> and a way to get server-side downscaling combined (with antialiasing)
> combined with client-side upscaling as a compression method...
---------------------------------------------------------------------
To unsubscribe, mail majordomo "at" uk.research.att.com with the line:
'unsubscribe vnc-list' in the message BODY
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------