* network: Only insert global addresses into the DHT.
Currently every address reported via libp2p-identify is inserted into
the DHT which thus contains a multitude of unreachable addresses such
as from 127.0.0.0/8 or 10.0.0.0/8.
Issue #5099 suggested a dedicated service over UDP to gauge the
reachability of an address, which would however incur extra I/O costs
and be of limited use.
As an alternative and simpler tactic, this PR only allows global IP
addresses to be inserted into the DHT unless an explicit command-line
flag `--allow-non-global-addresses-in-dht` is given or a node is
started with `--dev`. This opt-in behaviour is meant to allow
site-local networks to still make use of a DHT.
* Enable non-global in more test setups.
* Replace command-line option with different name.
* Another test fix.
If polling encounters a `Poll::Pending` we need to return it instead of
continuing the loop which may turn it into a blocking operation, causing
problems with executors.
* Log kademlia errors when get/put record fails.
The current approach makes it difficult to figure out what the
underlying error was, that made the operation fail.
* Formatting
Co-Authored-By: Pierre Krieger <pierre.krieger1708@gmail.com>
Co-authored-by: Pierre Krieger <pierre.krieger1708@gmail.com>
libp2p-0.16 allows configuring yamux through libp2p-yamux, so the
direct dependency is no longer needed.
While at it we also update to the latest versions of yamux and
nohash-hasher, though the code changes do not depend on it.
* network: Use "one shot" protocol handler.
Add two new `NetworkBehaviour`s, one handling remote block requests
and another one to handle light client requests (both local and from
remote). The change is motivated by the desire to use multiple
substreams of a single connection for different protocols. To achieve
this, libp2p's `OneShotHandler` is used as a protocol handler in each
behaviour. It will open a fresh substream for the duration of the
request and close it afterwards. For block requests, we currently only
handle incoming requests from remote and tests are missing. For light
client handling we support incoming requests from remote and also
ported a substantial amount of functionality over from
`light_dispatch.rs` (including several tests). However the result lacks
in at least two aspects:
(1) We require external updates w.r.t. the best block per peer and
currently nothing updates this information.
(2) We carry a lot of peer-related state around.
Both aspects could be simplified by externalising peer selection and
just requiring a specific peer ID where the request should be sent to.
We still have to maintain some peer related state due to the way
libp2p's swarm and network behaviour work (e.g. we must make sure to
always issue `NetworkBehaviourAction::SendEvent`s to peers we are
connected to, otherwise the actions die a silent death.
Another change implemented here is the use of protocol buffers as the
encoding for network messages. Certain individual fields of messages
are still SCALE encoded. There has been some discussion about this
in another PR (https://github.com/paritytech/substrate/pull/3452), so
far without resolution.
* Uncomment `Behaviour::light_client_request`.
* Add license headers.
* Add command-line flag to enable yamux flow control.
We never enabled proper flow-control for yamux streams which may cause
stream buffers to exceed their configured limit when the stream
producer outpaces the stream consumer. By switching the window update
mode to on-read, producers will only receive more sending credit when
all data has been consumed from the stream buffer. Using this option
creates backpressure on producers. However depending on the protocol
there is a risk of deadlock, if both endpoints concurrently attempt to
send more data than they have credit for and neither side reads before
finishing their writes. To facilitate proper testing, this PR adds a
command-line flag `use-yamux-flow-control`.
* Replace comment with generic message.
The current `debug_assert_eq` is clearly wrong as the code handles zero
response blocks. What should have been expressed is that we expect 0 or
1 response blocks.
This version fixes an issue with lifetime elision which causes
compilation to fail on recent rustc versions (e.g. 1.39.0-nightly
(bea0372a1 2019-08-20)).
See https://github.com/paritytech/soketto/pull/1 for more information.
Instead of passing a context around to each method, thereby introducing
side-effecting I/O actions everywhere, with this PR `sync::ChainSync`
only contains state which is updated by invoking various callback
methods (`on_*`) and actionable items are returned as regular results
from method calls, often iterators yielding requests that should be
issued to peers. It is up to the caller to handle these in an
appropriate way, currently `protocol` will send those as messages.
* Change network::sync::extra_requests to not send.
Instead it only maintains the invariants and leaves the actual I/O part
to the parent module (i.e. `sync`).
* Update Cargo.lock.
* Limit the set of known extrinsics and blocks.
* Update Cargo.lock
* Always insert and pop oldest entry if needed.
Always inserting first ensures that the element's LRU position is
updated.
