add: fundamentals doc on connections #202
Conversation
There was a problem hiding this comment.
Thanks for the follow-ups.
I think there is a lot of confusion here. Instead of continuing on the document, I think it would make more sense to help you understand these concepts in depth first.
I don't have the capacity to do this in the next week.
In case you would like to make progress on this in the meantime, maybe someone else from the team can help out.
In case you will be at LabWeek, we can sit together and talk through these.
| - **Peer-to-Peer (P2P)**: a distributed network in which workloads are | ||
| shared between *Peers*. |
There was a problem hiding this comment.
Does this belong in the connections documentation or in a general glossary?
Also referencing https://docs.ipfs.io/concepts/glossary/ just in case you haven't seen it yet.
| An interface called a [switch](/concepts/stream-multiplexing/#switch/swarm) | ||
| (and sometimes swarm) implements a basic dial queue that manages an application's | ||
| dialing and listening state. This prevents multiple, | ||
| simultaneous dial requests to the same peer. |
There was a problem hiding this comment.
Sorry in case I sparked confusion here before. As a data point, rust-libp2p manages a dial queue in its ConnectionPool and not in its Swarm.
I would drop these implementation specific terms here entirely.
Just my opinion. Maybe others feel strongly about it.
| ### How do peers know what transports other peers support? | ||
|
|
||
| Each libp2p node has information about the transports it supports. | ||
| Peers can obtain this information by dialing a peer and listen | ||
| for updates on the network. More information about peers is available | ||
| on the [peers guide](/concepts/peers). |
There was a problem hiding this comment.
I am guessing you are referring to the identify protocol?
I would suggest dropping this to avoid any confusion.
| to the listening peer, known as the *Responder* of the connection, via the Initiator's | ||
| multiaddr over the transport. To accept connections, a libp2p application registers |
There was a problem hiding this comment.
I am confused. Why is the initiator's multiaddr relevant here?
| ### How does the switch decide on which transport protocol to use? | ||
|
|
||
| The switch conducts a protocol negotiation process between two peers through an | ||
| interface known as [`multistream-select`](https://github.com/multiformats/multistream-select). | ||
| In particular, the multicodec is negotiated between two peers. |
There was a problem hiding this comment.
I don't think this is accurate.
A node learns about a peers multiaddresses. Based on these multiaddresses the local node dials one or more addresses, i.e. decides on one or more transport protocols.
|
|
||
| ### What happens when two peers do not support the same transport? | ||
|
|
||
| If a Responder doesn't support a particular protocol, they may respond with "na" |
There was a problem hiding this comment.
I think you are mixing a lot of concepts here.
With Transport are you referring to TCP and QUIC? If so, none of these are negotiated. The local node learns whether a remote peer supports one of these transports through the remote peer's multiaddresses.
| If a peer relies on a relay node to listen to a dial request, circuit relaying | ||
| creates a peer-to-peer circuit by adding the connection path to the connection | ||
| multiaddr. Thus, a listening peer can use the same path to dial back to a peer | ||
| that dialed to it. |
There was a problem hiding this comment.
This is confusing to me. A listening peer would need to know the local peer's multiaddr to dial back.
| Several security protocols are supported in libp2p for encryption, the two primary | ||
| ones being Noise and TLS 1.3. See the secure channel guide for more information on |
There was a problem hiding this comment.
Actually, these are the only ones.
Co-authored-by: Max Inden <[email protected]>
salmad3
added
change request
salmad3
changed the title
salmad3
changed the title
salmad3
added
wontfix
|
replaced by most recent linked PR. |
Context
Latest Preview
Please view the latest Fleek preview here.