update network-domains & node-discovery

This commit is contained in:
LordGhostX 2023-05-16 17:04:42 +01:00
parent 7ee00ba345
commit 5689db243e
No known key found for this signature in database
GPG Key ID: 520CC5DC4F94FCC7
3 changed files with 11 additions and 13 deletions

View File

@ -30,7 +30,8 @@
"QUIC",
"Dappnode",
"gameplay",
"Smol"
"Smol",
"Datagram"
],
"flagWords": [],
"ignorePaths": [

View File

@ -31,7 +31,7 @@ participant B as B relay(pubtopic1)
participant C as C relay(pubtopic1)
participant D as D relay(pubtopic1), store(pubtopic1), filter
participant E as E relay, store
participant F as F relay, filter
participant F as F filter
A ->> A: msg1=WakuMessage(contentTopic1, data) (1)
F ->> D: FilterRequest(pubtopic1, contentTopic1) (2)
@ -39,6 +39,7 @@ D ->> D: Subscribe F to filter (2)
A ->> B: Publish msg1 on pubtopic1 (3)
B ->> D: relay msg1 on pubtopic1 (3)
D ->> D: store: saves msg1 (4)
D ->> C: relay msg1 on pubtopic1 (4)
D ->> F: MessagePush(msg1) (5)
E ->> E: E comes online (6)
E ->> D: HistoryQuery(pubtopic1, contentTopic1) (6)
@ -50,6 +51,6 @@ The Pub/Sub topic `pubtopic1` serves as a means of routing messages (the network
1. Node A creates a WakuMessage `msg1` with a [ContentTopic](/overview/concepts/content-topics) `contentTopic1`.
2. Node F requests to get messages filtered by Pub/Sub topic `pubtopic1` and ContentTopic `contentTopic1`. Node D subscribes F to this filter and will forward messages that match that filter in the future.
3. Node A publishes `msg1` on `pubtopic1`. The message is sent from Node A to Node B and then forwarded to Node D.
4. Node D, upon receiving `msg1`, stores the message in its store for possible later retrieval by other nodes.
4. Node D, upon receiving `msg1` both stores the message for future retrieval by other nodes and forwards it to Node C.
5. Node D also pushes `msg1` to Node F, informing it about the arrival of a new message.
6. At a later time, Node E comes online and requests messages matching `pubtopic1` and `contentTopic1` from Node D. Node D responds with `msg1` and potentially other messages that match the query.

View File

@ -2,7 +2,7 @@
title: Node Discovery Mechanisms
---
When initializing a Waku node, it must connect with other nodes to enable message sending, receiving, and retrieval. To achieve this, a discovery mechanism is employed to locate other nodes where no connections are present. This process is known as bootstrapping.
When initializing a Waku node, it must connect with other nodes to enable message sending, receiving, and retrieval. To achieve this, a discovery mechanism is employed to locate and connect with other nodes. This process is known as bootstrapping.
After establishing a connection, the node must actively seek out additional peers to have:
@ -23,7 +23,7 @@ Waku applications have the flexibility to embed bootstrap node addresses directl
- Vulnerable to censorship: Node IPs can be blocked or restricted.
- Limited scalability: The number of nodes is fixed and cannot easily be expanded.
- Maintenance challenges: Updating the node list requires modifying the code, which can be cumbersome and less maintainable.
- Maintenance challenges: Updating the node list requires modifying the code, which can be cumbersome and involves releasing and deploying.
## [DNS Discovery](https://rfc.vac.dev/spec/31/)
@ -40,7 +40,7 @@ This bootstrapping method allows anyone to register and publish a domain name fo
#### Cons
- Vulnerable to censorship: Domain names can be blocked or restricted.
- Limited scalability: The number of nodes is fixed, and operators need to provide their `ENR` to the domain owner for listing.
- Limited scalability: The listed nodes are at risk of being overwhelmed by receiving all queries. Also, operators must provide their `ENR` to the domain owner for listing.
## [Discv5](https://rfc.vac.dev/spec/33/)
@ -53,16 +53,12 @@ This bootstrapping method allows anyone to register and publish a domain name fo
#### Cons
- Demands high resource allocation.
- Nodes hindered by restrictive NAT setups are unable to run this protocol.
- Requires lots of connections and involves frequent churn.
- Relies on User Datagram Protocol (UDP), which is not supported in web browsers.
## [Peer Exchange](https://rfc.vac.dev/spec/34/)
The primary objective of this protocol is to facilitate peer connectivity for resource-restricted devices. The peer exchange protocol enables lightweight nodes to request peers from other nodes within the network. Light nodes can bootstrap and expand their mesh independently without relying on [Discv5](#discv5) or bootstrap nodes.
:::info
This protocol is intended for situations where the use of `Discv5` is not feasible.
:::
The primary objective of this protocol is to facilitate peer connectivity for resource-restricted devices. The peer exchange protocol enables lightweight nodes to request peers from other nodes within the network. Light nodes can bootstrap and expand their mesh independently without relying on [Discv5](#discv5).
#### Pros