Fix more s&f architecture docs typo

This commit is contained in:
Devon Hudson 2023-01-11 11:14:07 -07:00
parent 2958ce76c6
commit b8bb0395c5
No known key found for this signature in database
GPG key ID: CD06B18E77F6A628

View file

@ -42,9 +42,9 @@ In the future this will probably need to change in order to handle more complex
- 0: This relay server is currently only acting on behalf of `P2P Node B`. It will only receive, and later forward events that are destined for `P2P Node B`.
- 1: When `P2P Node A` fails sending directly to `P2P Node B` (after a configurable number of attempts), it checks for any known relay servers associated with `P2P Node B` and sends to all of them.
- If sending to any of the relay servers succeeds, that transaction is considered to be successfully sent.
- 2: The relay server `forwarder` stores the transaction json in it's database and marks it as destined for `P2P Node B`.
- 3: When `P2P Node B` comes online, it queries all it's relay servers for any missed messages.
- 4: The relay server `retriever` will look in it's database for any transactions that are destined for `P2P Node B` and returns them one at a time.
- 2: The relay server `forwarder` stores the transaction json in its database and marks it as destined for `P2P Node B`.
- 3: When `P2P Node B` comes online, it queries all its relay servers for any missed messages.
- 4: The relay server `retriever` will look in its database for any transactions that are destined for `P2P Node B` and returns them one at a time.
For now, it is important that we dont design out a hybrid approach of having both sender-side and recipient-side relay servers.
Both approaches make sense and determining which makes for a better experience depends on the use case.