logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-01-02 14:13:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

languare fixes

Browse Source
This commit is contained in:
SionoiS 2024-10-22 10:50:34 -04:00
parent 18c24ef642
commit 53e75df59a
No known key found for this signature in database
GPG Key ID: C9458A8CB1852951
1 changed files with 27 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
standards/core/rendezvous.md
View File

@ -1,24 +1,25 @@
---
title: WAKU-RENDEZVOUS
name: Waku rendez vous discovery
name: Waku Rendezvous discovery
editor: Simon-Pierre Vivier <simvivier@status.im>
contributors:
---
## Abstract
This document describe the goal,
This document describes the goal,
strategy and usage of the libp2p rendezvous protocol by Waku.
Rendezvous is one of the discovery methods that can be used by Waku,
it supplements Discovery v5 and Waku peer exchange but fill a specific role.
Rendezvous is one of the discovery methods that can be used by Waku.
It supplements Discovery v5 and Waku peer exchange.
## Background and Rationale
How do new nodes join the network is the question that discovery answers.
Discovery must be fast, pertinent and resilient to attacks.
Rendezvous is both fast and allow the discovery of relevant peers,
although by it's design can be easily abused.
although it design can be easily abused
due to it's lack of protection against denial of service atacks.
The properties of rendezvous complements well the slower but safer methods like Discv5.
To contribute well, a Waku nodes must know a sufficient number of peers with
To contribute well, a Waku node must know a sufficient number of peers with
a wide variety of capabilities.
By using rendezvous in combination with
[Discv5](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md#node-discovery-protocol-v5) and
@ -27,26 +28,35 @@ Waku nodes will reach a good number of meaningful peers
faster than through a single discovery method.
## Semantics
Waku rendezvous fully inherit the [libp2p rendezvous semantics](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol).
Waku rendezvous fully inherits the [libp2p rendezvous semantics](https://github.com/libp2p/specs/blob/master/rendezvous/README.md#rendezvous-protocol).
## Specifications
The namespaces used to register and request will be in the format `rs/cluster-id/shard`.
The namespaces used to register and request MUST be in the format `rs/cluster-id/shard`.
Refer to [RELAY-SHARDING](https://github.com/waku-org/specs/blob/master/standards/core/relay-sharding.md) for cluster and shard information.
Every [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) node will also be initialized as a rendezvous point.
Every [Waku Relay](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/11/relay.md) node SHOULD be initialized as a rendezvous point.
Each relay node will register with random rendezvous points every 10 seconds,
once for each shard it supports and register only the namespace corresponding to that shard.
Each registrations will expire after 1 minute.
Each relay node that participates in discovery
MUST register with random rendezvous points at regular intervals.
At startup, every Waku nodes will discover peers by sending requests to random rendezvous points,
We RECOMMEND a registration interval of 10 seconds.
The node SHOULD register once for every shard it supports,
registering only the namespace corresponding to that shard.
We RECOMMEND that rendezvous points expire registrations after 1 minute,
in order to keep discovered peer records to those recentrly online.
At startup, every Waku node SHOULD discover peers by
sending requests to random rendezvous points,
once for each shard it supports.
A maximum of 12 peers will be requested each time.
We RECOMMEND a maximum of 12 peers will be requested each time.
This number is enough for good GossipSub connectivity and
minimize the load on rendezvous points.
It is assumed that the bootstrap node used is a rendezvous point and
that other discovery methods are used in conjunction and
will continue discovering peers for the lifetime of the node.
We RECOMMEND that bootstrap nodes participate in rendezvous discovery and
that other discovery methods are used in conjunction and
continue discovering peers for the lifetime of the local node.
## Future Work