On Tue, 4 Oct 2011 14:11:00 +0200 Pierre Ossman <oss...@cendio.se> wrote:
> (Cross-posting to both tigervnc-devel and rfbproto as this is a general > protocol issue, but tigervnc will be the playground for testing it) > > Hi, > > I'm looking at making VNC/RFB work better over high latency network. > Right now we're limited to one update per RTT, which makes things > rather unpleasant over many links. Things are still very much up in the > air, but I've written down my thoughts so far and I'd appreciate any > input you could give on it. You can find my notes here: > > https://sourceforge.net/apps/mediawiki/tigervnc/index.php?title=VNC_Latency_Considerations > > Rgds I was hoping for a bit more comments here, but I guess I have some understanding that this mess is something that people prefer to stay clear off. :) Anyway, I've updated the page linked above with more substantial info from my prototyping. I also have some idea on how the protocol needs to be augmented. The abstract portion of it is on that page, but I've also included patches for the protocol documentation that describes the details. Comments welcome. Rgds -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
Index: rfbproto.rst =================================================================== --- rfbproto.rst (revision 4741) +++ rfbproto.rst (working copy) @@ -828,6 +828,7 @@ 252 tight 251 `SetDesktopSize`_ 250 `xvp Client Message`_ +XXX `Fence Client Message`_ =========== =========================================================== Note that before sending a message with an optional message type a @@ -1477,6 +1478,72 @@ established that the server supports this extension, by requesting the `xvp Pseudo-encoding`_. +Fence Client Message +-------------------- + +A client supporting the *Fence* extension sends this to request a +synchronisation of the data stream. + +=============== ==================== ========== ======================= +No. of bytes Type [Value] Description +=============== ==================== ========== ======================= +1 ``U8`` XXX *message-type* +3 *padding* +4 ``U32`` *flags* +1 ``U8`` *length* +*length* ``U8`` array *payload* +=============== ==================== ========== ======================= + +The *flags* byte informs the server if this is a new request, or a +response to a server request sent earlier, as well as what kind of +synchronisation that is desired. + +=============== ======================================================= +Bit Description +=============== ======================================================= +0 **BlockBefore** +1 **BlockAfter** +2 **SyncNext** +3-30 Currently unused +31 **Request** +=============== ======================================================= + +The server should respond with the **Request** bit cleared, as well as +clearing any bits it does not understand. The remaining bits should +remain set in the response. This allows the client to determine which +flags the server supports when new ones are defined in the future. + +**BlockBefore** + All messages preceeding this one must have finished processing and + taken effect before the response is sent. + +**BlockAfter** + All messages following this one must not start processing until the + response is sent. + +**SyncNext** + The message following this one must be executed in an atomic manner + so that anything preceeding the fence response **must not** be + affected by the message, and anything following the fence response + *must* be affected by the message. The primary purpose of this + synchronisation is to allow safe usage of stream altering commands + such as `SetPixelFormat`_. + + If **BlockAfter** is set then that synchronisation must be relaxed + to allow processing of the following message. Any message after + that will still be affected by both flags though. + +**Request** + Indicates that this is a new request and that a response is + expected. If this bit is cleared then this message is a response to + an earlier request. + +The client can also include a chunk of data to differentiate between +responses and to avoid keeping state. This data is specified using +*length* and *payload*. The size of this data is limited to 64 bytes in +order to minimise the disturbance to highly parallel clients and +servers. + QEMU Client Message ------------------- @@ -1646,6 +1713,7 @@ 253 `gii Server Message`_ 252 tight 250 `xvp Server Message`_ +XXX `Fence Server Message`_ =========== =========================================================== Note that before sending a message with an optional message type a @@ -1834,6 +1902,14 @@ by sending a message with an XVP_FAIL *xvp-message-code*, and the same *xvp-extension-version* as included in the client's operation request. +Fence Server Message +-------------------- + +A server supporting the *Fence* extension sends this to request a +synchronisation of the data stream. The format and semantics is +identical to `Fence Client Message`_, but with the roles of the client +and server reversed. + QEMU Server Message ------------------- @@ -1937,6 +2013,7 @@ -307 `DesktopName Pseudo-encoding`_ -308 `ExtendedDesktopSize Pseudo-encoding`_ -309 `xvp Pseudo-encoding`_ +XXX `Fence Pseudo-encoding`_ -412 to -512 `JPEG Fine-Grained Quality Level Pseudo-encoding`_ -763 to -768 `JPEG Subsampling Level Pseudo-encoding`_ ============ ========================================================== @@ -2999,6 +3076,15 @@ *xvp-message-code* of *XVP_INIT*. This informs the client that it may then subsequently send messages of type `xvp Client Message`_. +Fence Pseudo-encoding +--------------------- + +A client which requests the *Fence* pseudo-encoding is declaring that it +supports and/or wishes to use the *Fence* extension. If the server +supports this, it replies with a message of type `Fence Server Message`_, +using any flags or payload. This informs the client that it may then +subsequently send messages of type `Fence Client Message`_. + JPEG Fine-Grained Quality Level Pseudo-encoding -----------------------------------------------
Index: rfbproto.rst =================================================================== --- rfbproto.rst (revision 4741) +++ rfbproto.rst (working copy) @@ -1937,6 +1997,7 @@ -307 `DesktopName Pseudo-encoding`_ -308 `ExtendedDesktopSize Pseudo-encoding`_ -309 `xvp Pseudo-encoding`_ +XXX `ContinuousUpdates Pseudo-encoding`_ -412 to -512 `JPEG Fine-Grained Quality Level Pseudo-encoding`_ -763 to -768 `JPEG Subsampling Level Pseudo-encoding`_ ============ ========================================================== @@ -2999,6 +3060,14 @@ *xvp-message-code* of *XVP_INIT*. This informs the client that it may then subsequently send messages of type `xvp Client Message`_. +ContinuousUpdates Pseudo-encoding +--------------------------------- + +A client which requests the *ContinuousUpdates* pseudo-encoding is +declaring that it wishes to use the `EnableContinuousUpdates`_ +extension. If the server supports this, it should respond with a +`EndOfContinuousUpdates`_ message. + JPEG Fine-Grained Quality Level Pseudo-encoding -----------------------------------------------
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
