10: Add overview (#340)

* 10: Add overview

* Add textual description

* Update diagram

* Tweak
This commit is contained in:
Oskar Thorén 2021-04-09 13:16:23 +08:00 committed by GitHub
parent c91eb64934
commit eb7942c6a4
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 57 additions and 0 deletions

View File

@ -109,6 +109,30 @@ See [13/WAKU2-STORE](/spec/13) spec for more details.
See [14/WAKU2-FILTER](/spec/14) spec for more details.
## Overview
See the sequence diagram below for an overview of how the different protocols interact.
<p align="center">
<img src="../../../../rfcs/10/overview.png" />
<br />
Figure 1: Overview of how protocols interact in Waku v2.
</p>
0. We have six nodes, A-F. The protocols initially mounted are indicated as such. The PubSub topics `pubtopic1` and `pubtopic2` is used for routing and indicates that it is subscribed to messages on that topic for relay, see [11/WAKU2-RELAY](/spec/11) for details. Ditto for [13/WAKU2-STORE](/spec/13) where it indicates that these messages are persisted on that node.
1. Node A creates a WakuMessage `msg1` with a ContentTopic `contentTopic1`. See [14/WAKU2-MESSAGE](/spec/14) for more details. If WakuMessage version is set to 1, we use the [6/WAKU1](/spec6) compatible `data` field with encryption. See [7/WAKU-DATA](/spec/7) for more details.
2. Node F requests to get messages filtered by PubSub topic `pubtopic1` and ContentTopic `contentTopic1`. Node D subscribes F to this filter and will in the future forward messages that match that filter. See [12/WAKU2-FILTER](/spec/12) for more details.
3. Node A publishes `msg1` on `pubtopic1` and subscribes to that relay topic pick it up. It then gets relayed further from B to D, but not C since it doesn't subscribe to that topic. See [11/WAKU2-RELAY](/spec/11).
4. Node D saves `msg1` for possible later retrieval by other nodes. See [13/WAKU2-STORE](/spec/13).
5. Node D also pushes `msg1` to F, as it has previously subscribed F to this filter. See [12/WAKU2-FILTER](/spec/12).
6. At a later time, Node E comes online. It then requests messages matching `pubtopic1` and `contentTopic1` from Node D. Node D responds with messages meeting this (and possibly other) criteria. See [13/WAKU2-STORE](/spec/13).
# Upgradability and Compatibility
## Compatibility with Waku v1

View File

@ -0,0 +1,33 @@
# Sequence diagram for Waku v2 (WakuMessage, WakuData, Relay, Store, Filter)
# PNG generated with https://mscgen.js.org
msc {
hscale="1",
wordwraparcs=true;
a [label="A\nrelay\n(0)"],
b [label="B relay(pubtopic1)\n(0)"],
c [label="C relay(pubtopic2)\n(0)"],
d [label="D relay(pubtopic1), store(pubtopic1), filter\n(0)"],
e [label="E\nrelay, store\n(0)"],
f [label="F\nrelay, filter\n(0)"];
a rbox a [label="msg1=WakuMessage(contentTopic1, data) [14/WAKU2-MESSAGE] (1)"];
a note a [label="If version=1, encrypt data per [7/WAKU-DATA] (1)"];
f => d [label="FilterRequest(pubtopic1, contentTopic1) [12/WAKU2-FILTER] (2)"];
d rbox d [label="Subscribe F to filter [12/WAKU2-FILTER] (2)"];
a => b [label="Publish msg1 on pubtopic1 [11/WAKU2-RELAY] (3)"];
b => d [label="relay msg1 on pubtopic1 [11/WAKU2-RELAY] (3)"];
d rbox d [label="store: saves msg1 [13/WAKU2-STORE] (4)"];
d => f [label="MessagePush(msg1)[12/WAKU2-FILTER] (5)"];
---;
e note e [label="E comes online (6)"];
e => d [label="HistoryQuery(pubtopic1, contentTopic1) [13/WAKU2-STORE] (6)"];
d => e [label="HistoryResponse(msg1, ...) [13/WAKU2-STORE] (6)"];
}

BIN
static/rfcs/10/overview.png Normal file

Binary file not shown.

After

Width:  |  Height:  |  Size: 72 KiB