I should warn everyone, I've just begun to wade through the protocol spec,
so I may not understand it in crucial places. With that said, I wanted to
chime in on the multicast discussion here:
>I considered a multicast extension to the protocol a long time ago. One
>problem you will have to overcome is that unless the client knows how many
>bits per pixel the server is using it will not be able to decode the buffer
>update messages from the server (it's a shame as there's an unused octet on
>the message header which could have been used to hold the information which
>would fix this and another very obscure problem with the point to point
>protocol).
I'm assuming you're talking about the "padding" byte that's second in each
FrameBufferUpdate? Yes, it does seem a shame. While I can see its
applicability to, say, degraded-color-mode sessions (such as the 4-bit
greyscale being discussed), why is it not reasonable for a multicast client
to be externally notified of basics such as the screen color details? I'll
spell that out more below...
>As you multicast uses datagrams |I think that you will also need to address
>the issue of buffer updates which are too large to fit in a single packet
>(you *really* don't want to send fragmented packets if you can help it).
>It's a rather interesting programming challenge to turn a single buffer
>update massage into n messages each smaller than m bytes ;)
True. And, from my (also limited) knowledge of multicast, there are a
couple of solutions that come to mind:
1) Overencoding. I forget the formalisms of this, but, basically, you
encode the data into n packets where you only need m to reconstruct the
original data. Since we're multicasting, I assume its fair to assume we can
waste bandwidth a little bit, right? This takes care of both the message
size (because you're already breaking up the messages), and, largely, the
recovery issues.
2) A more protocol-specific solution. This works, assuming either a certain
amount of "incomplete" screen display is correct, or that bandwidth is
actually highly available, and we're just trying to lessen load on the server.
- The server multicasts all screen updates. It either over-encodes, as
above, to split packets, or it never creates a frame buffer update that's
larger than the packet size. This could mean some really small packets,
yes, and, depending on whether the size is pre-restricted or not, the
server could have to try several sizes of break-up to get pieces of a given
screen region small enough to fit into such a packet.
- Clients either each have a TCP session to the server (this limits the
number of clients to a dozen to a couple of hundred, depending on
platform), or use a UDP port, but, in any case, all client traffice comes
trucked into the server.
- The server sends out updates depending on what screen updates the clients
have asked for.
What's wrong with this? Several things:
1) It's really hard for clients to join passively. A client might never get
a full-screen update.
2) A single high-bandwidth client can request updates at a frequency which
might swamp all slower-bandwidth viewers.
To solve those issues, I further suggest:
- The server would maintain several different "views" of what the clients
have seen. The 'high bandwidth" version would be the bleeding-edge - it
only differs from the "real" screen by whatever updates have been requested
but not yet dispatched. The 'high bandwidth' channel. Several exponentially
slower channels exist, each based on how often a screen update is served.
The second channel might dispatch screen updates for every 2 that are
requested, the third channel for every 4, etc. Higher multipliers can be
specified, if necessary. Now, the tricky part is what data is sent to each
channel. There are two ways to approach this:
1) Server has "tons" of bandwidth - Each degraded channel is independent.
Updates to the secondary channel, alone, build a consistent view of the
screen. Easier to implement, because you can actually drive an existing
server with multiple "shared" clients via an external driver, and let the
driver filter the incoming screen update requests as appropriate, and
handle multicast-encoding and whatnot for each channel/multicast address
2) Server has "less" bandwidth, clients have "more" - Each "channel"
includes updates from the one above it whenever it sends out updates. A
client must subscribe to all channels below the one for the quality it
wishes to view. Yes, clients will regularly receive duplicate copies of
screen updates (this is actually much like the over-encoding result, at the
application protocol layer). This one is harder to implement, though,
because you have to overhaul the client-handling sections of the VNC
server, or write a very heavy driver program which internally maintains the
different "screen state" representations. You obviously can't do it the
"cheap" way - just grouping the updates from upper channels - that doesn't
reduce bandwidth any. They key to the lower-channel usability is that
overlapping update regions, or regions of high change, will be encoded less
often, and thus require less bandwidth.
So, what are the impacts? Well, you need to write a client which can
subscribe to the appropriate multicast channel(s). And, either set up a
TCP-stream per client, or something. Since the client's gonna' have to find
basic stuff out, possibly authenticate, whatever, it seems like maybe a TCP
socket or UDP unicast setup phase that looks much like the current VNC
connection might be easier... the client can request a new encoding which
basically just means the server answers it with a listing of multicast
addresses to listen on, and effectively ends that "session".
Comments, or am I just full of drivel?
----------
Bryan Pendleton
ICQ: 2680952
Phone: (877)780-3087
"The root of all knowledge lies within, but knowledge is useless unless it
is collected and shared."
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
