-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update 1: Kickoff #1
Comments
Nice work getting this kicked off @gavinmcdermott 👏🏽👏🏽👏🏽👏🏽👏🏽 Let's chat about this on the libp2p hangout today :). Answers to your questions below:
Probs are sent in an interval (configurable). Not much, udp packets are cheap, and the replied (peer information) are only sent after a broadcast is sent.
It doesn't directly. peer-discovery mechanisms have a simple interface -- `.on('peer', doSomething) --, the interface is not formalized yet, but it is like https://github.com/libp2p/js-libp2p-mdns-discovery uses.
Inside the libp2p build (libp2p enables the dev to create several flavors of it, depending on their requirements), check libp2p-ipfs-browser, the browser build of js-ipfs, there we use the discovery mechanism offered by the WebRTC Transport (webrtc-star) to find other peers -> https://github.com/ipfs/js-libp2p-ipfs-browser/blob/master/src/index.js#L57-L59 In this example, we pass the responsibility to js-ipfs to decide what to do with the peer. (what js-ipfs does is ensuring it can dial and if so, add it to the PeerBook)
Peer Routing is a mechanism to 'find peers', the interface is designed to offer a dumb "find peers with this/for this id and returns PeerInfos that can be used to dial (it is expected that if a PeerInfo is returned, we can really dial to that peer)
👍👍👍👍👍 to this, it will make creating the tests easier. However, having tests where we actually 'blow up' or throttle the pipes of process will be even better (last mile is getting real hardware to run tests :D) |
I think the plan LGTM. May want to think through how the dockerization would work though up front-- may inform (1) and (2). |
Requesting input from @diasdavid
This weekend I've been working (and next week plan to work) on the test harness. Libp2p has a lot of surface area and supporting libs to understand; today I started moving through it piece by piece. Two things would be really helpful here:
Plan
Specific Questions (In order of importance)
Note: Please add as many comments to this repo's code in response as you'd like. All feedback is welcome
mdns
,random-walk
, etc.). In the naive example, every node connects to every node. I could be way off here, so some pointing in the right direction will help. To make it concrete, let's take the mdns sample for example:snr
relationship to a libp2p node instance?peerBook
?kad-router
(or any peer router) interacts with libp2p nodes.node.goIntermittent()
)testnet.triggerOutage({ pct: 30 })
)I really like the notion of triggering outages, latency, node drops and joins. But those can also come in once the basics are working. Just want to get initial thoughts out there.
And finally, based on what i'm desiring to do, if you think there's a better question to ask, or something missing, please let me know. Thanks for any feedback!
The text was updated successfully, but these errors were encountered: