-
Notifications
You must be signed in to change notification settings - Fork 232
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
libp2p spec #19
libp2p spec #19
Conversation
…n, and protocol muxing as building blocks of swarm
…w they are separated
Great progress!! 👍 (i can spend some time working on this too later this week.) |
we have three "discovery" protocols in go-ipfs running at the moment:
"peer discovery" is already a thing in other protocols and it typically means "finding more peers", not "finding a specific peer in the network". in dht-land, the coral + kademlia papers describe the query as a routing process. and call it a "routing table". Also, that's not what we've been calling "peer routing" either. recap:
Can we keep these names as they are? I've been talking to many people already about these. (Updated) |
|
||
**Identify** is one of the protocols mounted on top of swarm, our Connection handler, however, it follows and respects the same pattern as any other protocol when it comes to mounting it on top of swarm. Identify enables us to trade listenAddrs and observedAddrs between peers, this is crucial for the working of IPFS, since every socket open implements REUSEPORT, an observedAddr by another peer can enable a third peer to connect to us, since the port will be already open and redirect to us on a NAT. | ||
|
||
### 4.2.6 Relay |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think we can collect {Identify, Relay, NAT (there's multiple sub protocols for NAT), etc}
into a heading like "Connectivity Protocols"
, which layer over Swarm, but are part of (under) libp2p (libp2p.Node
).
@jbenet really nice review, thank you! :D Also great to be doing this now as we are noticing some final polishing on how things are done (glad that we are doing that while we are jumping into go-libp2p too) |
|
||
- `.openStream(peer, protocol)` - peer should contain the ID of the peer and its respective multiaddrs known. | ||
- `.registerHandler(protocol, handlerFunc)` - enable a protocol to be registered, so that another peer can open a stream to talk with us to that specific protocol | ||
- `.listen()` - to start listening for incoming connections and therefore opening of streams |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 👍 on this interface.
how about the below. This assumes that we don't sink protocol muxing into the Swarm, but again, that's up for discussion as it may be relevant to. regardless, we want users to use a libp2p.Node, not the Swarm directly.
// Node is the basic interface of libp2p. It represents a "Host" in the libp2p internet.
// It is capable of opening streams (either as a dialer or a listener) to other Nodes.
//
// The libp2p.Node uses a libp2p.Swarm internally to handle all connections and
// stream multiplexing.
//
// It is meant to have user protocols "mounted" onto the Node (as one would bind
// a socket and Listen, in a regular TCP/IP network stack). This is done with either
// the OpenStream or SetHandler functions (which represent Dialing or Listening)
// for stream of a specific protocol. Only one "client process" may mount a protocol,
// that means that only one Handler is registered per protocol.ID. This tends to be
// the convenient thing to do, but may be up for discussion (e.g. being part of
// multiple IPFS-DHTs, etc).
//
// The p2p.Node uses internal protocols (which are mounted on top, like any other
// protocol) such as Identify, NAT (traversal), and Relay, to achieve full connectivity
// on the networks it belongs to.
type p2p.Node interface {
// OpenStream opens a reliable stream to peer.ID with given protocol.ID.
// If there is no prior connection to peer.ID, p2p.Node will attempt to establish one.
OpenStream(peer.ID, protocol.ID)
// SetHandler registers a function to be called whenever another peer opens a stream
// with that specific protocol.ID. If HandlerFunc is nil (default), the handler writes an
// ProtocolNotFoundError back and closes the stream.
SetHandler(protocol.ID, protocol.HandlerFunc)
// Listen starts listening for incoming connections and therefore opening of streams
// (this may need to handle the addresses, i'll look again at how go-libp2p does it).
Listen()
// this will need more things here, will look into go-libp2p to figure this out.
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The interface has evolved a lil bit with the last 'Swarm revisit' to support multiprotocols, but it is essentially the same:
https://github.com/diasdavid/node-libp2p-swarm#usage
we want users to use a libp2p.Node, not the Swarm directly.
Totally agree, we can have a 'front facing' interface from libp2p, in fact node-libp2p is just that, glue, take a peak at:
https://github.com/diasdavid/node-libp2p#setting-everything-up
Glad to remove the prefixes and make it everything libp2p.
From @jbenet and @diasdavid discussion
|
ping :) |
I'm going to merge this, we can make edits as we go. |
weeeee! :D |
It is getting form :) still a working progress, but leaving a PR here so people can start watching it, make comments, reviews, etc :)