mirror of
https://github.com/acid-info/waku.guide.git
synced 2025-02-23 07:18:19 +00:00
update network-domains & node-discovery
This commit is contained in:
parent
7ee00ba345
commit
5689db243e
@ -30,7 +30,8 @@
|
||||
"QUIC",
|
||||
"Dappnode",
|
||||
"gameplay",
|
||||
"Smol"
|
||||
"Smol",
|
||||
"Datagram"
|
||||
],
|
||||
"flagWords": [],
|
||||
"ignorePaths": [
|
||||
|
@ -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.
|
@ -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
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user