Uh oh!
There was an error while loading. Please reload this page.
Describe peer discovery in ADR - #33
Conversation
Number 003 is selected, because 002 is proposed in #29.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| 1. There will be a set of well-known, application-agnostic seed nodes. Every optimint client will be able to connect to such node, addresses will be saved in configuration. | ||
| * This does not limit applications which can create independent networks, with separate set of seed nodes. | ||
| 2. Nodes in the network will serve DHT. It will be used for active peer discovery. Client of each ORU network will be able to find other peers in this particular network. | ||
| * All nodes will cooperate on the same DHT. |
There was a problem hiding this comment.
| * All nodes will cooperate on the same DHT. | |
| * Nodes of different ORU chains will cooperate on the same DHT. |
There was a problem hiding this comment.
Is this incorrect? "All nodes" is rather unspecific IMO.
Uh oh!
There was an error while loading. Please reload this page.
| ## Alternatives | ||
| 1. IPFS DHT for peer discovery. | ||
| 2. Custom peer-exchange protocol. |
There was a problem hiding this comment.
It would be even better if we'd briefly list pros/cons for these too.
Co-authored-by: Ismail Khoffi <Ismail.Khoffi@gmail.com>
Co-authored-by: Ismail Khoffi <Ismail.Khoffi@gmail.com>
Co-authored-by: Ismail Khoffi <Ismail.Khoffi@gmail.com>
| @@ -0,0 +1,23 @@ | |||
| # Peer Discovery | |||
| Libp2p provides multiple ways to discover peers (DHT, mDNS). Currently there are no plans to support mDNS (as it's limited to local networks). | |||
There was a problem hiding this comment.
Note: PEx in PubSub is also a way to discover peers
| * There may be some overhead for clients to handle DHT requests from other ORU networks. | ||
| ## Alternatives | ||
| 1. IPFS DHT for peer discovery. |
There was a problem hiding this comment.
We are using IPFS DHT technology already, so I think the alternative is confusing.
There was a problem hiding this comment.
I suggest mentioning in Proposed network architecture that we are building a fully independent DHT network and joining public IPFS's one as an alternative.
| ### Cons | ||
| * There may be some overhead for clients to handle DHT requests from other ORU networks. | ||
| ## Alternatives |
There was a problem hiding this comment.
As an alternative we can also specify discv5 from geth
There was a problem hiding this comment.
Additionally, the alternative would be running an independent DHT network for each ORU
Wondertan
commented
Mar 29, 2021
@tzdybal, it is also worth mentioning separate PubSub network(along with doing so). Both DHT and PubSub allows setting custom protocol ID so connected nodes won't speak even running the same engine(DHT, PubSub). So basically custom protocol ID == custom network |
tzdybal
commented
Mar 30, 2021
Thanks for comments and suggestions. Everything is addressed, please re-review. |
Number 003 is selected, because 002 is proposed in #29.