Broadcast known message optimization
- Dominant language
- Rust
- Stars
- 283
- Forks
- 34
- PR merge metrics
- No merged PRs in 30d
Description
I hope it's ok, if I ask a question here. I'm wondering about the optimization introduced in this commit here: https://github.com/jonhoo/rustengan/commit/d96079dd211e85f859dd36af15332b562cbaa778
I'm curious why this particular optimization was chosen. It seems to me there would be other ways of achieving this that are more obvious (to me at least) and would work better. Like acknowledging "gossip" messages with a "gossip_ok" messages and updating `known` when receiving a "gossip_ok" message. That would also allow for a couple of follow-up optimizations like not sending "gossip" messages, when all messages are known to the other node. You can further include messages in "gossip_ok" to gossip back.
Having said that I'm also new to distributed systems, so I suspect I might be missing something rather important and the above is a terrible idea for some reason. So I'd really appreciate to learn more about why you chose to optimize it in this way.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.