Skip to content
  1. Jan 21, 2021
  3. Jan 20, 2021
  5. Jan 19, 2021
  7. Jan 18, 2021
  9. Jan 17, 2021
  11. Jan 15, 2021
  13. Jan 14, 2021
  15. Jan 13, 2021
  17. Jan 12, 2021
  19. Jan 11, 2021
  21. Jan 08, 2021
    • asynchronous rob's avatar
      subsystems have an unbounded channel to the overseer (#2236) · 03e39cf5
      asynchronous rob authored 
      

* subsystems have an unbounded channel to the overseer

* Update node/overseer/src/lib.rs

Co-authored-by: default avatarBernhard Schuster <[email protected]>

* bump Cargo.lock

Co-authored-by: default avatarBernhard Schuster <[email protected]>
      03e39cf5
    • Bastian Köcher's avatar
      Do not send empty view updates to peers (#2233) · 475915ff
      Bastian Köcher authored 
      

* Do not send empty view updates to peers

It happened that we send empty view updates to our peers, because we
only updated our finalized block. This could lead to situations where we
overwhelmed sub systems with too many messages. On Rococo this lead to
constant restarts of our nodes, because some node apparently was
finalizing a lot of blocks.

To prevent this, the pr is doing the following:

1. If a peer sends us an empty view, we report this peer and decrease it
reputation.

2. We ensure that we only send a view update when the `heads` changed
and not only the `finalized_number`.

3. We do not send empty `ActiveLeavesUpdates` from the overseer, as this
makes no sense to send these empty updates. If some subsystem is relying
on the finalized block, it needs to listen for the overseer signal.

* Update node/network/bridge/src/lib.rs

Co-authored-by: default avatarPeter Goodspeed-Niklaus <[email protected]>

* Don't work if they're are no added heads

* Fix test

* Ahhh

* More fixes

Co-authored-by: default avatarPeter Goodspeed-Niklaus <[email protected]>
      475915ff
    • Fedor Sakharov's avatar
      Exit from av-store loop on fatal error. (#2232) · 8f293e18
      Fedor Sakharov authored 
      * Fuse receive stream in Context

* Revert "Fuse receive stream in Context"

This reverts commit ddd26fa98f0ca1afbc22064e93010e4193a058b2.

* Exit on node shutdown from av-store loop

* Filter only context error
      8f293e18
  23. Jan 07, 2021
  25. Jan 06, 2021
    • ordian's avatar
      upgrade a few dependencies (companion for 7831) (#2205) · a0a5f4cf
      ordian authored 
      * upgrade a few dependencies

* "Update Substrate"

Co-authored-by: parity-processbot <>
      a0a5f4cf
    • felix's avatar
      added new bootnode to chain spec's (#2204) · 9d07e99c
      felix authored 
      * added new bootnode to chain spec's

* remove trailing newline
      9d07e99c
    • Peter Goodspeed-Niklaus's avatar
      Add metrics timing message passing from OverseerSubsystemContext to Overseer::route_message (#2201) · cd58c02c
      Peter Goodspeed-Niklaus authored 
      * add timing setup to OverseerSubsystemContext

* figure out how to initialize the rng

* attach a timer to a portion of the messages traveling to the Overseer

This timer only exists / logs a fraction of the time (configurable
by `MESSAGE_TIMER_METRIC_CAPTURE_RATE`). When it exists, it tracks
the span between the `OverSubsystemContext` receiving the message
and its receipt in `Overseer::run`.

* propagate message timing to the start of route_message

This should be more accurate; it ensures that the timer runs
at least as long as that function. As `route_message` is async,
it may not actually run for some time after it is called (or ever).

* fix failing test

* rand_chacha apparently implicitly has getrandom feature

* change rng initialization

The previous impl using `from_entropy` depends on the `getrandom`
crate, which uses the system entropy source, and which does not
work on `wasm32-unknown-unknown` because it wants to fall back to
a JS implementation which we can't assume exists.

This impl depends only on `rand::thread_rng`, which has no documentation
stating that it's similarly limited.

* remove randomness in favor of a simpler 1 of N procedure

This deserves a bit of explanation, as the motivating issue explicitly
requested randomness. In short, it's hard to get randomness to compile
for `wasm32-unknown-unknown` because that is explicitly intended to be
as deterministic as practical. Additionally, even though it would never
be used for consensus purposes, it still felt offputting to intentionally
introduce randomness into a node's operations. Except, it wasn't really
random, either: it was a deterministic PRNG varying only in its state,
and getting the state to work right for that target would have required
initializing from a constant.

Given that it was a deterministic sequence anyway, it seemed much simpler
and more explicit to simply select one of each N messages instead of
attempting any kind of realistic randomness.

* reinstate randomness for better statistical properties

This partially reverts commit 0ab8594c328b3f9ce1f696fe405556d4000630e9.

`oorandom` is much lighter than the previous `rand`-based implementation,
which makes this easier to work with.

This implementation gives each subsystem and each child RNG a distinct
increment, which should ensure they produce distinct streams of values.
      cd58c02c