A few weeks ago when I was debugging my wrong setup with kademlia, I could not conveniently debug `RoutingUpdate` after adding an address to the DHT. It would be nice to have a few derivable traits on a public enum.
Pull-Request: #4270.
The `rate-limiter` module was not made publicly available. This change exports the `RateLimiter` trait defined within that module which allows users to define their own rate limiters. To make common usecases easy, we also provide a set of constructor functions for common rate limiters.
Resolves#3741.
Pull-Request: #3742.
By default, dialing is prevented when already connected. `kad` already checks this manually before doing dials. By changing the condition from `Disconnected` to `NotDialing`, we prevent simultaneous dials to a peer.
Pull-Request: #4224.
Currently, `Limit` is supplied to many of relay client events, however there is no way to access the fields. This PR adds functions to allow access to the data from those fields.
Pull-Request: #4162.
The current implementation in Kademlia relies on an external address to determine if it should be in client or server mode. However there are instances where a node, which may know an external address, wishes to remain in client mode and switch to server mode at a later point.
This PR introduces `Kademlia::set_mode`, which accepts an `Option<Mode>` that would allow one to set `Mode::Client` for client mode, `Mode::Server` for server mode, or `None` to determine if we should operate as a client or server based on our external addresses.
Resolves#4074.
Pull-Request: #4132.
Adds back in Distance as a public type. Follows `KBucketKey` naming for clarity.
Resolves#4108.
Pull-Request: #4109.
Co-Authored-By: Josh Wilson <joshuef@gmail.com>
Co-Authored-By: Max Inden <mail@max-inden.de>
This resolves an issue where our tests were depending on the number of network interfaces available on the local machine.
Related #4110.
Pull-Request: #4122.
Co-Authored-By: Thomas Eizinger <thomas@eizinger.io>
Instead of exposing the time to establish a connection, the time to upload the bytes and the time to download the bytes, expose a single time including all three.
The rational here is, that differentiation of the three is flawed. E.g. when does one stop the upload timer and start the download timer? When the last byte is sent? When the last byte is flushed? When the first byte is received?
See https://github.com/libp2p/test-plans/pull/184#pullrequestreview-1482600521 for past discussion.
Pull-Request: #4105.
Co-Authored-By: Max Inden <mail@max-inden.de>
Using workspace inheritance breaks `cargo release` because it cannot resolve that the dev-dependencies should only use a `path` and not a version.
Pull-Request: #4097.
Co-Authored-By: Thomas Eizinger <thomas@eizinger.io>
> 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.
Remove the use of the core `upgrade::transfer` module in `ping` example (`request-response` protocol) in favor of `cbor` codec.
Related #4011.
Pull-Request: #4046.
Currently, the kademlia behaviour can only learn that the remote node supports kademlia on a particular connection if we successfully negotiate a stream to them.
Using the newly introduced abstractions from #3651, we don't have to attempt to establish a stream to the remote to learn whether they support kademlia on a connection but we can directly learn it from the `ConnectionEvent::RemoteProtocolsChange` event. This happens directly once a connection is established which should overall benefit the DHT.
Clients do not advertise the kademlia protocol and thus we will immediately learn that a given connection is not suitable for kadmelia requests. We may receive inbound messages from it but this does not affect the routing table.
Resolves: #2032.
Pull-Request: #3877.
