libp2p swarm implementation in JavaScript.
libp2p-swarm is a connection abstraction that is able to leverage several transports and connection upgrades, such as congestion control, channel encryption, the multiplexing of several streams in one connection, and more. It does this by bringing protocol multiplexing to the application level (instead of the traditional Port level) using multicodec and multistream.
libp2p-swarm is used by libp2p but it can be also used as a standalone module.
libp2p-swarm is available on npm and so, like any other npm module, just:
> npm install libp2p-swarm --save
And use it in your Node.js code as:
const Swarm = require('libp2p-swarm')
const sw = new Swarm(peerInfo)
peerInfo is a PeerInfo object that represents the peer creating this swarm instance.
libp2p-swarm expects transports that implement interface-transport. For example libp2p-tcp.
key
- the transport identifier.transport
-options
-callback
-
Dial to a peer on a specific transport.
key
multiaddrs
callback
Set a transport to start listening mode.
key
options
handler
callback
Close the listeners of a given transport.
key
callback
A connection upgrade must be able to receive and return something that implements the interface-connection specification.
WIP
Upgrading a connection to use a stream muxer is still considered an upgrade, but a special case since once this connection is applied, the returned obj will implement the interface-stream-muxer spec.
muxer
Enable the identify protocol.
Enable a specified crypto protocol. By default no encryption is used, aka plaintext
. If called with no arguments it resets to use plaintext
.
You can use for example libp2p-secio like this
const secio = require('libp2p-secio')
swarm.connection.crypto(secio.tag, secio.encrypt)
dial uses the best transport (whatever works first, in the future we can have some criteria), and jump starts the connection until the point where we have to negotiate the protocol. If a muxer is available, then drop the muxer onto that connection. Good to warm up connections or to check for connectivity. If we have already a muxer for that peerInfo, then do nothing.
pi
- peer info projectprotocol
callback
Hang up the muxed connection we have with the peer.
pi
- peer info projectcallback
Start listening on all added transports that are available on the current peerInfo
.
Handle a new protocol.
protocol
handlerFunc
- function called when we receive a dial onprotocol. Signature must be
function (protocol, conn) {}`matchFunc
- matchFunc for multistream-select
Unhandle a protocol.
protocol
Close all the listeners and muxers.
callback
We expose a streaming interface based on pull-streams
, rather then on the Node.js core streams implementation (aka Node.js streams). pull-streams
offers us a better mechanism for error handling and flow control guarantees. If you would like to know more about why we did this, see the discussion at this issue.
You can learn more about pull-streams at:
- The history of Node.js streams, nodebp April 2014
- The history of streams, 2016
- pull-streams, the simple streaming primitive
- pull-streams documentation
If you are a Node.js streams user, you can convert a pull-stream to a Node.js stream using the module pull-stream-to-stream
, giving you an instance of a Node.js stream that is linked to the pull-stream. For example:
const pullToStream = require('pull-stream-to-stream')
const nodeStreamInstance = pullToStream(pullStreamInstance)
// nodeStreamInstance is an instance of a Node.js Stream
To learn more about this utility, visit https://pull-stream.github.io/#pull-stream-to-stream.
libp2p is designed to support multiple transports at the same time. While peers are identified by their ID (which are generated from their public keys), the addresses of each pair may vary, depending the device where they are being run or the network in which they are accessible through.
In order for a transport to be supported, it has to follow the interface-transport spec.
Each connection in libp2p follows the interface-connection spec. This design decision enables libp2p to have upgradable transports.
We think of upgrade
as a very important notion when we are talking about connections, we can see mechanisms like: stream multiplexing, congestion control, encrypted channels, multipath, simulcast, etc, as upgrades
to a connection. A connection can be a simple and with no guarantees, drop a packet on the network with a destination thing, a transport in the other hand can be a connection and or a set of different upgrades that are mounted on top of each other, giving extra functionality to that connection and therefore upgrading
it.
Types of upgrades to a connection:
- encrypted channel (with TLS for e.g)
- congestion flow (some transports don't have it by default)
- multipath (open several connections and abstract it as a single connection)
- simulcast (still really thinking this one through, it might be interesting to send a packet through different connections under some hard network circumstances)
- stream-muxer - this a special case, because once we upgrade a connection to a stream-muxer, we can open more streams (multiplex them) on a single stream, also enabling us to reuse the underlying dialed transport
We also want to enable flexibility when it comes to upgrading a connection, for example, we might that all dialed transports pass through the encrypted channel upgrade, but not the congestion flow, specially when a transport might have already some underlying properties (UDP vs TCP vs WebRTC vs every other transport protocol)
Identify is a protocol that Swarms mounts on top of itself, to identify the connections between any two peers. E.g:
- a) peer A dials a conn to peer B
- b) that conn gets upgraded to a stream multiplexer that both peers agree
- c) peer B executes de identify protocol
- d) peer B now can open streams to peer A, knowing which is the identity of peer A
In addition to this, we also share the 'observed addresses' by the other peer, which is extremely useful information for different kinds of network topologies.
To avoid the confusion between connection, stream, transport, and other names that represent an abstraction of data flow between two points, we use terms as:
- connection - something that implements the transversal expectations of a stream between two peers, including the benefits of using a stream plus having a way to do half duplex, full duplex
- transport - something that as a dial/listen interface and return objs that implement a connection interface
This module is actively under development. Please check out the issues and submit PRs!
MIT © Protocol Labs