This documents the fence messages that can be used to synchronise
other messages, and to measure network and processing delays between
the client and server.
Signed-off-by: Pierre Ossman
---
Index: rfbproto.rst
===
--- rfbproto.rst(revision 4793)
+++ rfbproto.rst(working copy)
@@ -847,7 +847,7 @@
127 VMWare
128 Car Connectivity
150 `EnableContinuousUpdates`_
-248 ClientFence
+248 `ClientFence`_
249 OLIVE Call Control
250 `xvp Client Message`_
251 `SetDesktopSize`_
@@ -1193,6 +1193,75 @@
however be honored, even if the area in such a request does not overlap
the area specified for continuous updates.
+ClientFence
+---
+
+A client supporting the *Fence* extension sends this to request a
+synchronisation of the data stream.
+
+=== == ===
+No. of bytesType [Value]Description
+=== == ===
+1 ``U8`` 248*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. The server should not delay the
+response more than necessary, even if the synchronisation requirements
+would allow it.
+
+=== ===
+Bit Description
+=== ===
+0 **BlockBefore**
+1 **BlockAfter**
+2 **SyncNext**
+3-30Currently unused
+31 **Request**
+=== ===
+
+The server should respond with a `ServerFence`_ 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.
+
xvp Client Message
--
@@ -1723,7 +1792,7 @@
128 Car Connectivity
150 `EndOfContinuousUpdates`_
173 [#off]_ ServerState
-248 ServerFence
+248 `ServerFence`_
249 OLIVE Call Control
250 `xvp Server Message`_
252 tight
@@ -1856,6 +1925,25 @@
1 ``U8`` 150*message-type*
=== == ===
+ServerFence
+---
+
+A server supporting the *Fence* extension sends this to request a
+synchronisation of the data stream.
+
+=== == ===
+No. of bytesType [Value]Description
+=== == ===
+1 ``U8`` 248*message-type*
+3 *padding*
+4 ``U32`` *flags*
+1 ``U8`` *length*
+*length*``U8`` array*payload*
+=== == ===
+
+The format and semantics
