archive
/
matrix-spec-proposals
mirror of https://github.com/matrix-org/matrix-spec-proposals
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update 3618-simplify-federation-send.md

Browse Source
neilalexander/msc/send
Neil Alexander 4 years ago committed by GitHub
parent 33bff5d0af
commit dad0c7dac2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 10 additions and 8 deletions
Show Stats Download Patch File Download Diff File

18
proposals/3618-simplify-federation-send.md
Unescape Escape View File

@ -31,9 +31,9 @@ that we return only one of two conditions:
## Benefits ## Benefits
A significant benefit is that the receiving homeserver no longer needs to block A significant benefit is that the receiving homeserver no longer needs to block the
the `/send` request in order to wait for the events to be processed for their error the `/send` request in order to wait for the events to be processed for their `PDU Processing
results. Result`s.
Given that it is possible for a transaction to contain events from multiple rooms, or Given that it is possible for a transaction to contain events from multiple rooms, or
EDUs for unrelated purposes, it is bad that a single busy room can lengthen the amount of EDUs for unrelated purposes, it is bad that a single busy room can lengthen the amount of
@ -44,10 +44,10 @@ per the spec:
> The sending server must wait and retry for a 200 OK response before sending a > The sending server must wait and retry for a 200 OK response before sending a
> transaction with a different txnId to the receiving server. > transaction with a different txnId to the receiving server.
With this proposal, the receiving server needing to block the `/send` response to wait for With this proposal, the receiving server no longer needs to wait for `PDU Processing Result`s
`PDU Processing Result`s becomes optional rather than required. Receiving servers that do as this MSC does away with them. Receiving servers that do not want to durably persist transactions
not want to durably persist transactions before processing them can continue to perform all before processing them can continue to perform all work in-memory by continuing to block the `/send`
work in-memory by continuing to block on `/send` as is done today. Additionally, a receiving request until all processing is completed, as may be done today. Additionally, a receiving
server that is receiving too many transactions from a remote homeserver may wish to block for server that is receiving too many transactions from a remote homeserver may wish to block for
an arbitrary period of time for rate-limiting purposes, but this is an implementation specific an arbitrary period of time for rate-limiting purposes, but this is an implementation specific
detail and not strictly required. detail and not strictly required.
@ -58,4 +58,6 @@ observing the HTTP status code.
## Potential issues ## Potential issues
Synapse appears to use the `"pdus"` key for logging (see [here](https://github.com/matrix-org/synapse/blob/b38bdae3a2e5b7cfe862580368b996b8d7dfa50f/synapse/federation/sender/transaction_manager.py#L160)). Dendrite, however, ignores the response body altogether. Synapse appears to use the `"pdus"` key for logging (see [here](https://github.com/matrix-org/synapse/blob/b38bdae3a2e5b7cfe862580368b996b8d7dfa50f/synapse/federation/sender/transaction_manager.py#L160)).
Conduit does the same and treats the response as an empty list if it is not present. Dendrite
ignores the response body altogether.

Write Preview
Loading…
Cancel
Save