• Max Inden's avatar
    client/finality-grandpa: Reintegrate periodic neighbor packet worker (#4631) · d4fbb897
    Max Inden authored
    The `NeighborPacketWorker` within `client/finality-grandpa` does two
    things:
    
    1. It receives neighbor packets from components within
    `client/finality-grandpa`, sends them down to the `GossipEngine` in
    order for neighboring nodes to receive.
    
    2. It periodically sends out the most recent neighbor packet to the
    `GossipEngine`.
    
    In order to send out packets it had a clone to a `GossipEgine` within
    an atomic reference counter and a mutex. The `NeighborPacketWorker` was
    then spawned onto its own asynchronous task.
    
    Instead of running in its own task, this patch reintegrates the
    `NeighborPacketWorker` into the main `client/finality-grandpa` task not
    requiring the `NeighborPacketWorker` to own a clone of the
    `GossipEngine`.
    
    The greater picture
    
    This is a tiny change within a greater refactoring. The overall goal is
    to **simplify** how finality-grandpa interacts with the network and to
    **reduce** the amount of **unbounded channels** within the logic.
    
    Why no unbounded channels: Bounding channels is needed for backpressure
    and proper scheduling. With unbounded channels there is no way of
    telling the producer side to slow down for the consumer side to catch
    up.  Rephrased, there is no way for the scheduler to know when to favour
    the consumer task over the producer task on a crowded channel and the
    other way round for an empty channel.
    
    Reducing the amount of shared ownership simplifies the logic and enables
    one to use async-await syntax-suggar, given that one does not need to
    hold a lock across poll invocations. Using async-await enables one to
    use bounded channels without complex logic.
    d4fbb897