Renamed the following
- `dns::GenDnsConfig` -> `dns::Config`
- `dns::DnsConfig` -> `dns::async_std::Config`
- `dns::TokioDnsConfig` -> `dns::tokio::Config`
If async-std feature is enable, use `dns::async_std::Config`. When using tokio, import `dns::tokio::Config` . There is no need to use `dns::Config` directly.
Resolves#4486.
Related: #2217.
Pull-Request: #4505.
When we moved our examples, the hole-punching docs were not updated for the new names of the binaries. We adjust them such that the tutorial works again.
Pull-Request: #4458.
- Cut a stable release of `libp2p-quic`.
- Export `libp2p-quic` as `libp2p::quic`.
- Update examples to use `libp2p-quic` through `libp2p`.
Pull-Request: #4325.
Implement `Transport::dial_as_listener` for QUIC as specified by the [DCUtR spec](https://github.com/libp2p/specs/blob/master/relay/DCUtR.md).
To facilitate hole punching in QUIC, one side needs to send random UDP packets to establish a mapping in the routing table of the NAT device. If successful, our listener will emit a new inbound connection. This connection needs to then be sent to the dialing task. We achieve this by storing a `HashMap` of hole punch attempts indexed by the remote's `SocketAddr`. A matching incoming connection is then sent via a oneshot channel to the dialing task which continues with upgrading the connection.
Related #2883.
Pull-Request: #3964.
> Observed addresses (aka. external address candidates) of the local node, reported by a remote node
> via `libp2p-identify`, are no longer automatically considered confirmed external addresses, in
> other words they are no longer trusted by default. Instead users need to confirm the reported
> observed address either manually, or by using `libp2p-autonat`. In trusted environments users can
> simply extract observed addresses from a `libp2p-identify::Event::Received { info:
> libp2p_identify::Info { observed_addr }}` and confirm them via `Swarm::add_external_address`.
Follow-up to https://github.com/libp2p/rust-libp2p/pull/3954.
Pull-Request: #4052.
Previously, the associated types on `NetworkBehaviour` and `ConnectionHandler` carried generic names like `InEvent` and `OutEvent`. These names are _correct_ in that `OutEvent`s are passed out and `InEvent`s are passed in but they don't help users understand how these types are used.
In theory, a `ConnectionHandler` could be used separately from `NetworkBehaviour`s but that is highly unlikely. Thus, we rename these associated types to indicate, where the message is going to be sent to:
- `NetworkBehaviour::OutEvent` is renamed to `ToSwarm`: It describes the message(s) a `NetworkBehaviour` can emit to the `Swarm`. The user is going to receive those in `SwarmEvent::Behaviour`.
- `ConnectionHandler::InEvent` is renamed to `FromBehaviour`: It describes the message(s) a `ConnectionHandler` can receive from its behaviour via `ConnectionHandler::on_swarm_event`. The `NetworkBehaviour` can send it via the `ToSwarm::NotifyHandler` command.
- `ConnectionHandler::OutEvent` is renamed to `ToBehaviour`: It describes the message(s) a `ConnectionHandler` can send back to the behaviour via the now also renamed `ConnectionHandlerEvent::NotifyBehaviour` (previously `ConnectionHandlerEvent::Custom`)
Resolves: #2854.
Pull-Request: #3848.
In the libp2p specs, the only handshake pattern that is specified is the XX handshake. Support for other handshake patterns can be added through external modules. While we are at it, we rename the remaining types to following the laid out naming convention.
The tests for handshakes other than XX are removed. The handshakes still work as we don't touch them in this patch.
Related #2217.
Pull-Request: #3768.
Due to cargo's feature unification, a full build of our workspace doesn't actually check whether the examples compile as standalone projects.
We add a new CI check that iterates through all crates in the `examples/` directory and runs a plain `cargo check` on them. Any failure is bubbled up via `set -e`, thus failing CI in case one of the `cargo check` commands fails.
To fix the current failures, we construct a simple TCP transport everywhere where we were previously using `development_transport`. That is because `development_transport` requires `mplex` which is now deprecated.
Related #3657.
Related #3809.
Pull-Request: #3811.
Currently, our top-level `Cargo.toml` manifest represents a crate AND a workspace. This causes surprising behaviour (e.g. #2949) where we need to explicitly pass `--workpace` to every command to run it on the entire workspace and not just the meta crate.
My moving the meta crate into its own directory, the root manifest file is a virtual manifest only and thus, every `cargo` command will automatically default to running on the entire workspace.
On top of this, I personally find it easier to understand if workspace and crate manifests are not mixed.
Pull-Request: #3536.
