Add instructions on how to run a three node example where a listening
relay client listens via a relay server and a dialing relay client dials
the listening relay client via the relay server.
mdns keeps rediscovering nodes. this PR changes that to only emit events for new
nodes it discovered. In addition we make sure to only send a query if it is
really needed. Some logging is added for debugging purposes.
Changes in 45f07bf8 now seem to append `/p2p/<peer>` to multiaddr passed to
transports. The regex in transport/wasm-ext doesn't support this fully qualified
format. This commit adjusts the regex accordingly.
If you start listening after mdns joined a multicast group, the peers may not
discover eachother until the 5min timeout expires.
Co-authored-by: Max Inden <mail@max-inden.de>
With `rand` `v0.8.0` platform support changed [1] due to its upgrade to
`getrandom` `v0.2`. With `getrandom` `v0.2` `wasm32-unknown-unknown` is no
longer supported out of the box:
> This crate fully supports the wasm32-wasi and wasm32-unknown-emscripten
> targets. However, the wasm32-unknown-unknown target is not automatically
> supported since, from the target name alone, we cannot deduce which JavaScript
> interface is in use (or if JavaScript is available at all).
>
> Instead, if the "js" Cargo feature is enabled, this crate will assume that you
> are building for an environment containing JavaScript, and will call the
> appropriate methods. Both web browser (main window and Web Workers) and
> Node.js environments are supported, invoking the methods described above using
> the wasm-bindgen toolchain.
>
> This feature has no effect on targets other than wasm32-unknown-unknown.
This commit drops support for wasm32-unknown-unknown in favor of the two more
specific targets wasm32-wasi and wasm32-unknown-emscripten.
Note on `resolver = "2"`: The new resolver is required to prevent features
being mixed, more specifically to prevent libp2p-noise to build with the
`ring-resolver` feature. See [3] for details.
---
[1] https://github.com/rust-random/rand/blob/master/CHANGELOG.md#platform-support
[2] https://docs.rs/getrandom/0.2.2/getrandom/#webassembly-support
[3] https://doc.rust-lang.org/nightly/cargo/reference/features.html#feature-resolver-version-2
Instead of fully executing benchmarks, i.e. running multiple iterations,
each measured and recorded, only test that they compile and run them
with a single execution to make sure they work. The benefit is a reduced
CI runtime.
Flag documentation:
> To test that the benchmarks run successfully without performing the
measurement or analysis (eg. in a CI setting), use cargo test --benches.
https://bheisler.github.io/criterion.rs/book/user_guide/command_line_options.html
The above assumes that (a) the benchmark results from CI are likely
noisy and thus (b) no one actually looks at the benchmark results.
This commit extends the ping example in `src/tutorial.rs, by walking a
newcomer through the implementation of a simple ping node step-by-step,
introducing all the core libp2p concepts along the way.
With the ping tutorial in place, there is no need for the lengthy libp2p
crate level introduction, which is thus removed with this commit.
Co-authored-by: Roman Borschel <romanb@users.noreply.github.com>
Remove `Deref` and `DerefMut` implementations previously dereferencing
to the `NetworkBehaviour` on `Swarm`. Instead one can access the
`NetworkBehaviour` via `Swarm::behaviour` and `Swarm::behaviour_mut`.
Methods on `Swarm` can now be accessed directly, e.g. via
`my_swarm.local_peer_id()`.
Reasoning: Accessing the `NetworkBehaviour` of a `Swarm` through `Deref`
and `DerefMut` instead of a method call is an unnecessary complication,
especially for newcomers. In addition, `Swarm` is not a smart-pointer
and should thus not make use of `Deref` and `DerefMut`, see documentation
from the standard library below.
> Deref should only be implemented for smart pointers to avoid
confusion.
https://doc.rust-lang.org/std/ops/trait.Deref.html
* Implement /ipfs/id/push/1.0.0 alongside some refactoring.
* Implement /ipfs/id/push/1.0.0, i.e. the ability to actively
push information of the local peer to specific remotes.
* Make the initial delay as well as the recurring delay
for the periodic identification requests configurable,
introducing `IdentifyConfig`.
* Fix test.
* Fix example.
* Update protocols/identify/src/identify.rs
Co-authored-by: Max Inden <mail@max-inden.de>
* Update protocols/identify/src/identify.rs
Co-authored-by: Max Inden <mail@max-inden.de>
* Update versions and changelogs.
Co-authored-by: Max Inden <mail@max-inden.de>
Add notable users:
- ipfs-embed. Rust IPFS implementation with a focus on being embeddable into rust applications
- actyx, platform for writing manufacturing applications, based on rust-libp2p
libp2p-dns requires a new feature in parity-multiaddr v0.11.2 namely
Multiaddr::ends_with. libp2p-dns does not depend on parity-multiaddr
directly but through libp2p-core. Prepare a new version of libp2p-core
requiring at least parity-multiaddr v0.11.2 and update libp2p-dns to
require libp2p-core v0.28.1.
* Implement `/dnsaddr` support on `libp2p-dns`.
To that end, since resolving `/dnsaddr` addresses needs
"fully qualified" multiaddresses when dialing, i.e. those
that end with the `/p2p/...` protocol, we make sure that
dialing always uses such fully qualified addresses by
appending the `/p2p` protocol as necessary. As a side-effect,
this adds support for dialing peers via "fully qualified"
addresses, as an alternative to using a `PeerId` together
with a `Multiaddr` with or without the `/p2p` protocol.
* Adapt libp2p-relay.
* Update versions, changelogs and small cleanups.
* README: Express preference for Github issues for questions
* README: Remove IRC and mention Discussions forum
Co-authored-by: Roman Borschel <romanb@users.noreply.github.com>
* [libp2p-dns] Use trust-dns-resolver.
Use the `trust-dns-resolver` library for DNS resolution,
thereby removing current use of the thread pool.
Since `trust-dns-resolver` and related crates already
provide support for both `async-std` and `tokio`, we
make use of that here in our own feature flags.
Since `trust-dns-resolver` provides many useful
configuration options and error detail, central
types of `trust-dns-resolver` like `ResolverConfig`,
`ResolverOpts` and `ResolveError` are re-exposed
in the API of `libp2p-dns`. Full encapsulation
does not seem preferable in this case.
* Cleanup
* Fix two intra-doc links.
* Simplify slightly.
* Incorporate review feedback.
* Remove git dependency and fix example.
* Update version and changelogs.
