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: Duration
When 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: Duration
This 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: Duration
Timeout after which [IHave
] messages are pushed to peers.
optimization_threshold: Round
The 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: Duration
Duration 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: Duration
Duration 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: Duration
How often the internal caches will be checked for expired items.