mirror of
https://github.com/element-hq/synapse.git
synced 2024-11-25 02:55:46 +03:00
deploy: 9228ae633f
This commit is contained in:
MatMaul
parent
efc2c93048
commit
a2ab700eb9
4 changed files with 12 additions and 10 deletions
|
|
@ -17433,7 +17433,7 @@ position of all streams. The server then periodically sends <code>RDATA</code> c
|
|||
which have the format <code>RDATA <stream_name> <instance_name> <token> <row></code>, where
|
||||
the format of <code><row></code> is defined by the individual streams. The
|
||||
<code><instance_name></code> is the name of the Synapse process that generated the data
|
||||
(usually "master").</p>
|
||||
(usually "master"). We expect an RDATA for every row in the DB.</p>
|
||||
<p>Error reporting happens by either the client or server sending an ERROR
|
||||
command, and usually the connection will be closed.</p>
|
||||
<p>Since the protocol is a simple line based, its possible to manually
|
||||
|
|
@ -17500,7 +17500,7 @@ reconnect, following the steps above.</p>
|
|||
<p>If the server sends messages faster than the client can consume them the
|
||||
server will first buffer a (fairly large) number of commands and then
|
||||
disconnect the client. This ensures that we don't queue up an unbounded
|
||||
number of commands in memory and gives us a potential oppurtunity to
|
||||
number of commands in memory and gives us a potential opportunity to
|
||||
squawk loudly. When/if the client recovers it can reconnect to the
|
||||
server and ask for missed messages.</p>
|
||||
<h3 id="reliability"><a class="header" href="#reliability">Reliability</a></h3>
|
||||
|
|
@ -17511,7 +17511,7 @@ disappears.</p>
|
|||
since these include tokens which can be used to restart the stream on
|
||||
connection errors.</p>
|
||||
<p>The client should keep track of the token in the last RDATA command
|
||||
received for each stream so that on reconneciton it can start streaming
|
||||
received for each stream so that on reconnection it can start streaming
|
||||
from the correct place. Note: not all RDATA have valid tokens due to
|
||||
batching. See <code>RdataCommand</code> for more details.</p>
|
||||
<h3 id="example-5"><a class="header" href="#example-5">Example</a></h3>
|
||||
|
|
@ -17562,7 +17562,8 @@ request to the appropriate process.</p>
|
|||
<p>Two positions are included, the "new" position and the last position sent respectively.
|
||||
This allows servers to tell instances that the positions have advanced but no
|
||||
data has been written, without clients needlessly checking to see if they
|
||||
have missed any updates.</p>
|
||||
have missed any updates. Instances will only fetch stuff if there is a gap between
|
||||
their current position and the given last position.</p>
|
||||
<h4 id="error-s-c"><a class="header" href="#error-s-c">ERROR (S, C)</a></h4>
|
||||
<p>There was an error</p>
|
||||
<h4 id="ping-s-c"><a class="header" href="#ping-s-c">PING (S, C)</a></h4>
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
|
|
@ -168,7 +168,7 @@ position of all streams. The server then periodically sends <code>RDATA</code> c
|
|||
which have the format <code>RDATA <stream_name> <instance_name> <token> <row></code>, where
|
||||
the format of <code><row></code> is defined by the individual streams. The
|
||||
<code><instance_name></code> is the name of the Synapse process that generated the data
|
||||
(usually "master").</p>
|
||||
(usually "master"). We expect an RDATA for every row in the DB.</p>
|
||||
<p>Error reporting happens by either the client or server sending an ERROR
|
||||
command, and usually the connection will be closed.</p>
|
||||
<p>Since the protocol is a simple line based, its possible to manually
|
||||
|
|
@ -235,7 +235,7 @@ reconnect, following the steps above.</p>
|
|||
<p>If the server sends messages faster than the client can consume them the
|
||||
server will first buffer a (fairly large) number of commands and then
|
||||
disconnect the client. This ensures that we don't queue up an unbounded
|
||||
number of commands in memory and gives us a potential oppurtunity to
|
||||
number of commands in memory and gives us a potential opportunity to
|
||||
squawk loudly. When/if the client recovers it can reconnect to the
|
||||
server and ask for missed messages.</p>
|
||||
<h3 id="reliability"><a class="header" href="#reliability">Reliability</a></h3>
|
||||
|
|
@ -246,7 +246,7 @@ disappears.</p>
|
|||
since these include tokens which can be used to restart the stream on
|
||||
connection errors.</p>
|
||||
<p>The client should keep track of the token in the last RDATA command
|
||||
received for each stream so that on reconneciton it can start streaming
|
||||
received for each stream so that on reconnection it can start streaming
|
||||
from the correct place. Note: not all RDATA have valid tokens due to
|
||||
batching. See <code>RdataCommand</code> for more details.</p>
|
||||
<h3 id="example"><a class="header" href="#example">Example</a></h3>
|
||||
|
|
@ -297,7 +297,8 @@ request to the appropriate process.</p>
|
|||
<p>Two positions are included, the "new" position and the last position sent respectively.
|
||||
This allows servers to tell instances that the positions have advanced but no
|
||||
data has been written, without clients needlessly checking to see if they
|
||||
have missed any updates.</p>
|
||||
have missed any updates. Instances will only fetch stuff if there is a gap between
|
||||
their current position and the given last position.</p>
|
||||
<h4 id="error-s-c"><a class="header" href="#error-s-c">ERROR (S, C)</a></h4>
|
||||
<p>There was an error</p>
|
||||
<h4 id="ping-s-c"><a class="header" href="#ping-s-c">PING (S, C)</a></h4>
|
||||
|
|
|
|||
Loading…
Reference in a new issue