@@ -15,15 +15,17 @@ example flow would be (where '>' indicates master to worker and
1515
1616 > SERVER example.com
1717 < REPLICATE
18- > POSITION events 53
19- > RDATA events 54 ["$foo1:bar.com", ...]
20- > RDATA events 55 ["$foo4:bar.com", ...]
18+ > POSITION events master 53
19+ > RDATA events master 54 ["$foo1:bar.com", ...]
20+ > RDATA events master 55 ["$foo4:bar.com", ...]
2121
2222The example shows the server accepting a new connection and sending its identity
2323with the ` SERVER ` command, followed by the client server to respond with the
2424position of all streams. The server then periodically sends ` RDATA ` commands
25- which have the format ` RDATA <stream_name> <token> <row> ` , where the format of
26- ` <row> ` is defined by the individual streams.
25+ which have the format ` RDATA <stream_name> <instance_name> <token> <row> ` , where
26+ the format of ` <row> ` is defined by the individual streams. The
27+ ` <instance_name> ` is the name of the Synapse process that generated the data
28+ (usually "master").
2729
2830Error reporting happens by either the client or server sending an ERROR
2931command, and usually the connection will be closed.
@@ -52,7 +54,7 @@ The basic structure of the protocol is line based, where the initial
5254word of each line specifies the command. The rest of the line is parsed
5355based on the command. For example, the RDATA command is defined as:
5456
55- RDATA <stream_name> <token> <row_json>
57+ RDATA <stream_name> <instance_name> < token> <row_json>
5658
5759(Note that <row_json> may contains spaces, but cannot contain
5860newlines.)
@@ -136,11 +138,11 @@ the wire:
136138 < NAME synapse.app.appservice
137139 < PING 1490197665618
138140 < REPLICATE
139- > POSITION events 1
140- > POSITION backfill 1
141- > POSITION caches 1
142- > RDATA caches 2 ["get_user_by_id",["@01register-user:localhost:8823"],1490197670513]
143- > RDATA events 14 ["$149019767112vOHxz:localhost:8823",
141+ > POSITION events master 1
142+ > POSITION backfill master 1
143+ > POSITION caches master 1
144+ > RDATA caches master 2 ["get_user_by_id",["@01register-user:localhost:8823"],1490197670513]
145+ > RDATA events master 14 ["$149019767112vOHxz:localhost:8823",
144146 "!AFDCvgApUmpdfVjIXm:localhost:8823","m.room.guest_access","",null]
145147 < PING 1490197675618
146148 > ERROR server stopping
@@ -151,10 +153,10 @@ position without needing to send data with the `RDATA` command.
151153
152154An example of a batched set of ` RDATA ` is:
153155
154- > RDATA caches batch ["get_user_by_id",["@test:localhost:8823"],1490197670513]
155- > RDATA caches batch ["get_user_by_id",["@test2:localhost:8823"],1490197670513]
156- > RDATA caches batch ["get_user_by_id",["@test3:localhost:8823"],1490197670513]
157- > RDATA caches 54 ["get_user_by_id",["@test4:localhost:8823"],1490197670513]
156+ > RDATA caches master batch ["get_user_by_id",["@test:localhost:8823"],1490197670513]
157+ > RDATA caches master batch ["get_user_by_id",["@test2:localhost:8823"],1490197670513]
158+ > RDATA caches master batch ["get_user_by_id",["@test3:localhost:8823"],1490197670513]
159+ > RDATA caches master 54 ["get_user_by_id",["@test4:localhost:8823"],1490197670513]
158160
159161In this case the client shouldn't advance their caches token until it
160162sees the the last ` RDATA ` .
@@ -178,6 +180,11 @@ client (C):
178180 updates, and if so then fetch them out of band. Sent in response to a
179181 REPLICATE command (but can happen at any time).
180182
183+ The POSITION command includes the source of the stream. Currently all streams
184+ are written by a single process (usually "master"). If fetching missing
185+ updates via HTTP API, rather than via the DB, then processes should make the
186+ request to the appropriate process.
187+
181188#### ERROR (S, C)
182189
183190 There was an error
@@ -234,12 +241,12 @@ Each individual cache invalidation results in a row being sent down
234241replication, which includes the cache name (the name of the function)
235242and they key to invalidate. For example:
236243
237- > RDATA caches 550953771 ["get_user_by_id", ["@bob:example.com"], 1550574873251]
244+ > RDATA caches master 550953771 ["get_user_by_id", ["@bob:example.com"], 1550574873251]
238245
239246Alternatively, an entire cache can be invalidated by sending down a ` null `
240247instead of the key. For example:
241248
242- > RDATA caches 550953772 ["get_user_by_id", null, 1550574873252]
249+ > RDATA caches master 550953772 ["get_user_by_id", null, 1550574873252]
243250
244251However, there are times when a number of caches need to be invalidated
245252at the same time with the same key. To reduce traffic we batch those
0 commit comments