You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: doc/CONFIGURATION.md
+1-3
Original file line number
Diff line number
Diff line change
@@ -204,7 +204,7 @@ Moreover, the majority of the modules can be customized via option parameters. T
204
204
Besides the `modules` and `config`, libp2p allows other internal options and configurations:
205
205
-`datastore`: an instance of [ipfs/interface-datastore](https://github.com/ipfs/interface-datastore/) modules.
206
206
- This is used in modules such as the DHT. If it is not provided, `js-libp2p` will use an in memory datastore.
207
-
-`peerId`: a previously computed instance of [libp2p/js-peer-id](https://github.com/libp2p/js-peer-id).
207
+
-`peerId`: the identity of the node, an instance of [libp2p/js-peer-id](https://github.com/libp2p/js-peer-id).
208
208
- This is particularly useful if you want to reuse the same `peer-id`, as well as for modules like `libp2p-delegated-content-routing`, which need a `peer-id` in their instantiation.
209
209
-`addresses`: an object containing `listen`, `announce` and `noAnnounce` properties with `Array<string>`:
210
210
-`listen` addresses will be provided to the libp2p underlying transports for listening on them.
@@ -215,8 +215,6 @@ Besides the `modules` and `config`, libp2p allows other internal options and con
215
215
216
216
#### Basic setup
217
217
218
-
TODO: should we add to the basic setup the configuration of listen addresses? we should probably make it a required option?
Copy file name to clipboardexpand all lines: doc/GETTING_STARTED.md
+9-2
Original file line number
Diff line number
Diff line change
@@ -136,15 +136,16 @@ If you want to know more about libp2p stream multiplexing, you should read the f
136
136
137
137
Now that you have configured a [**Transport**][transport], [**Crypto**][crypto] and [**Stream Multiplexer**](streamMuxer) module, you can start your libp2p node. We can start and stop libp2p using the [`libp2p.start()`](./API.md#start) and [`libp2p.stop()`](./API.md#stop) methods.
Copy file name to clipboardexpand all lines: src/address-manager/README.md
+6-6
Original file line number
Diff line number
Diff line change
@@ -8,9 +8,9 @@ These Addresses should be specified in your libp2p [configuration](../../doc/CON
8
8
9
9
A libp2p node should have a set of listen addresses, which will be used by libp2p underlying transports to listen for dials from other nodes in the network.
10
10
11
-
Before a libp2p node starts, a set of listen addresses should be provided to the AddressManager, so that when the node is started, the libp2p transports can use them to listen for connections. Accordingly, listen addresses should be specified through the libp2p configuration, in order to have the `AddressManager` created with them.
11
+
Before a libp2p node starts, its configured listen addresses will be passed to the AddressManager, so that during startup the libp2p transports can use them to listen for connections. Accordingly, listen addresses should be specified through the libp2p configuration, in order to have the `AddressManager` created with them.
12
12
13
-
It is important pointing out that libp2p accepts to listen on addresses that intend to rely on any available local port. In this context, the provided listen addresses might not be exactly the same as the ones used by the transports. For example tcp may replace `/ip4/0.0.0.0/tcp/0` with something like `/ip4/0.0.0.0/tcp/8989`. As a consequence, libp2p should take into account this when advertising its addresses.
13
+
It is important pointing out that libp2p accepts ephemeral listening addresses. In this context, the provided listen addresses might not be exactly the same as the ones used by the transports. For example TCP may replace `/ip4/0.0.0.0/tcp/0` with something like `/ip4/127.0.0.1/tcp/8989`. As a consequence, libp2p should take into account this when determining its advertised addresses.
14
14
15
15
## Announce Addresses
16
16
@@ -22,13 +22,13 @@ Scenarios for Announce Addresses include:
22
22
23
23
## No Announce Addresses
24
24
25
-
While we need to add Announce Addresses to enable peers' connectivity, we can also not announce addresses that will not be reachable. This way, No Announce Addresses should be specified so that they are not announced by the peer as addresses that other peers can use to dial it.
25
+
While we need to add Announce Addresses to enable peers' connectivity, we should also avoid announcing addresses that will not be reachable. No Announce Addresses should be specified so that they are filtered from the advertised multiaddrs.
26
26
27
-
As stated into the Listen Addresses section, Listen Addresses might get modified after libp2p transports get in action and use them to listen for new connections. This way, libp2p should also take into account these changes so that they can be matched when No Announce Addresses are being filtered out for advertising addresses.
27
+
As stated in the Listen Addresses section, Listen Addresses might be modified by libp2p transports after the successfully bind to those addresses. Libp2p should also take these changes into account so that they can be matched when No Announce Addresses are being filtered out of the advertised multiaddrs.
28
28
29
29
## Implementation
30
30
31
-
When a libp2p node is created, the Address Manager will be populated from the provided addresses through the libp2p configuration. Once the node is started, the Transport Manager component will gather the listen addresses from the Address Manager, so that the libp2p transports use them to listen on.
31
+
When a libp2p node is created, the Address Manager will be populated from the provided addresses through the libp2p configuration. Once the node is started, the Transport Manager component will gather the listen addresses from the Address Manager, so that the libp2p transports can attempt to bind to them.
32
32
33
33
Libp2p will use the the Address Manager as the source of truth when advertising the peers addresses. After all transports are ready, other libp2p components/subsystems will kickoff, namely the Identify Service and the DHT. Both of them will announce the node addresses to the other peers in the network. The announce and noAnnounce addresses will have an important role here and will be gathered by libp2p to compute its current addresses to advertise everytime it is needed.
34
34
@@ -40,7 +40,7 @@ In a future iteration, we can enable these addresses to be modified in runtime.
40
40
41
41
#### Modify Listen Addresses
42
42
43
-
While adding new addresses to listen on runtime is a feasible operation, removing one listen address might have bad implications for the node, since all the connections using that listen address will be closed. With this in mind and taking also into consideration the lack of good use cases for removing listen addresses, the Address Manager API only allows libp2p users to add new Listen Addresses on runtime.
43
+
While adding new addresses to listen on runtime should be trivial, removing a listen address might have bad implications for the node, since all the connections using that listen address will be closed. However, libp2p should provide a mechanism for both adding and removing listen addresses in the future.
44
44
45
45
Every time a new listen address is added, the Address Manager should emit an event with the new multiaddrs to listen. The Transport Manager should listen to this events and act accordingly.
0 commit comments