Iterative dissemination
nulltea opened this issue · comments
timofey commented
Summary
- current dissemination strategies are recursive, this one is the alternative to them
- overview: originator asks the closest known peers it whether they know closer ones to the given keys, if they don’t originator sends them samples to store, otherwise originator keeps asking peers it receives until it reaches the closest known ones
- it should be trivial to do using a custom protocol over
TALK_REQ
, no need to changeDiscv5
orOverlayProtocol
logic
Specification
- originator groups samples by known closest peers using the bucket-wise or distance-wise strategy, and sends batches of keys as
KEYS(Vec<SampleKey>)
to individual nodes - for each received key node checks if it knows nodes who are closer to that key, if it finds such nodes it responds with
CLOSER_NODES(SampleKey, Vec<Enr>)
, otherwise withSTORE(SampleKey)
(these can be grouped asSTORE(Vec<SampleKey>)
but UDP packet size limitation should be considered or use uTP instead). - for each
STORE
response, the originator sendsSAMPLES(Vec<SampleValue>)
- for each
CLOSER_NODES
response, the originator repeats the first step including newly discovered peers. - dissemination finishes when all samples are passed to the closest discovered nodes
timofey commented
Response approaches:
FullResponse {strore: Vec<SampleValue>, closer_enrs: Vec<Enr>}
- send values for all elements instore
; apply allenrs
to batching (how?)- series of (index, total,
CLOSER_NODES(SampleKey, Vec<Enr>)
|STORE(Vec<SampleKey>)
) - series of (index, total,
CLOSER_NODES(SampleKey, Vec<Enr>)
|STORE(Vec<SampleKey>)
) OptimizedResponse(Vec<Enr>)
- based on received Enrs and remote node_id, originator figures out which values to send and which keys continue to search
timofey commented
Benchmarks (256 keys, 800 nodes, no redundancies):
- with Libp2p: time.busy:18.5µs time.idle:760ms
- communication overhead = 920 messages
- storage overhead = 256 keys
- with Discv5: time.busy:19.5µs time.idle:6.21s
- communication overhead = 996 messages
- storage overhead = 256 keys