pub struct PlumtreeConfig {
pub graft_timeout_1: Duration,
pub graft_timeout_2: Duration,
pub dispatch_timeout: Duration,
pub optimization_threshold: Round,
pub message_cache_retention: Duration,
pub message_id_retention: Duration,
pub cache_evict_interval: Duration,
}Expand description
Configuration for the gossip broadcast layer.
Currently, the expectation is that the configuration is the same for all peers in the network (as recommended in the paper).
Fields§
§graft_timeout_1: DurationWhen receiving an [IHave] message, this timeout is registered. If the message for the
[IHave] was not received once the timeout is expired, a [Graft] message is sent to the
peer that sent us the [IHave] to request the message payload.
The plumtree paper notes:
The timeout value is a protocol parameter that should be configured considering the diameter of the overlay and a target maximum recovery latency, defined by the application requirements. (p.8)
graft_timeout_2: DurationThis timeout is registered when sending a [Graft] message. If a reply has not been
received once the timeout expires, we send another [Graft] message to the next peer that
sent us an [IHave] for this message.
The plumtree paper notes:
This second timeout value should be smaller that the first, in the order of an average round trip time to a neighbor.
dispatch_timeout: DurationTimeout after which [IHave] messages are pushed to peers.
optimization_threshold: RoundThe protocol performs a tree optimization, which promotes lazy peers to eager peers if the
[Message::IHave] messages received from them have a lower number of hops from the
message’s origin as the [InEvent::Broadcast] messages received from our eager peers. This
parameter is the number of hops that the lazy peers must be closer to the origin than our
eager peers to be promoted to become an eager peer.
message_cache_retention: DurationDuration for which to keep gossip messages in the internal message cache.
Messages broadcast from this node or received from other nodes are kept in an internal cache for this duration before being evicted. If this is too low, other nodes will not be able to retrieve messages once they need them. If this is high, the cache will grow.
Should be at least around several round trip times to peers.
message_id_retention: DurationDuration for which to keep the [MessageId]s for received messages.
Should be at least as long as Self::message_cache_retention, usually will be longer to
not accidentally receive messages multiple times.
cache_evict_interval: DurationHow often the internal caches will be checked for expired items.