Hello,
This message mostly addresses developers of standard AT&T's version of
VNC. I'm developing certain add-ons for VNC and I'm faced with one
problem of standard RFB protocol.
1. The Problem
==============
Current implementation of the RFB protocol sends a number of screen
rectangles as part of every server screen update. First, this number
of rectangles is sent; then, actual rectangles data follow. The
problem is that the server must know the number of rectangles before
sending them to client. After this number has been sent, the server is
not able to send another number of rectangles.
Why this is a problem? First, it makes very difficult or impossible to
efficiently break rectangles into smaller parts depending on their
content (not only on their size).
Second, it prevents server code from being able to react to client
events arriving during large framebuffer update. I think it could be
useful to dynamically change framebuffer update contents depending on
events received from RFB clients and windowing system.
2. Possible Solution
====================
Possible solution I like the most is to use one more pseudo-encoding
number (i.e. 0xFFFFFF20, actual value does not matter but it should
not be used by any existing RFB encodings).
If a client has announced that it supports this pseudo-encoding type,
the server could send arbitrary large value for number of rectangles
(i.e. 0xFFFF value) and use this pseudo-encoding number in the last,
additional rectangle header which is not followed by any data.
This solution increases the length of framebuffer update by 12 bytes
but this overhead may be considered negligible in most situations.
More important that this approach is compatible with standard VNC and
does not add much complexity to the code of RFB protocol parsers.
3. Request For Comments
=======================
Now about why I'm posting this message. Mostly, I'd like to know
position of official VNC developers on described problem. I think the
fact a server should send a number of following rectangles is a real
problem of current RFB protocol and maybe future major versions of the
protocol could deal with this problem in a more elegant way as
compared to the [temporary] solution described above.
--
With Best Wishes,
Constantin
---------------------------------------------------------------------
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
---------------------------------------------------------------------
