Is there a more active way to indicate that a node expects to die? Say, a shutdown handler that manually evicts itself from the cluster with a last, 'I'm dead' state. Would this be useful?
Decentralized cluster membership in Rust
11–20 of 21 posts
Re: Decentralized cluster membership in Rust
#12Is there a more active way to indicate that a node expects to die? Say, a shutdown handler that manually evicts itself from the cluster with a last, 'I'm dead' state. Would this be useful?
Then you have to differentiate between accidental and intentional death. Much more robust not to make that distinction.
Re: Decentralized cluster membership in Rust
#13Is there a more active way to indicate that a node expects to die? Say, a shutdown handler that manually evicts itself from the cluster with a last, 'I'm dead' state. Would this be useful?
Usually that's modeled in the application layer. In scuttlebutt you'd store a higher-level state as one of the node-specific parameters. The gossip protocol doesn't need to know that you know the node knows it's about to die, though there are optimizations to be made there.
Despite what the sibling commenter claims, in a production system you absolutely need that distinction -- not in terms of the reliability of the low-level protocol, but in terms of the application features you want to expose. A node about to be removed needs a chance to drain active connections.
Re: Decentralized cluster membership in Rust
#14Is this related to [Secure] Scuttlebutt (SSB), or just using the same name?
Re: Decentralized cluster membership in Rust
#15Is there a more active way to indicate that a node expects to die? Say, a shutdown handler that manually evicts itself from the cluster with a last, 'I'm dead' state. Would this be useful?
Depending on the need, it can be implemented on client side as well as on chitchat. We actually thought of this feature as a way for a node to normaly exclude itself from the cluster (maybe for application update). We are still evaluating how necessary this is because a node crash or normal shutdown can just work. Future experience will surely tell us.
Re: Decentralized cluster membership in Rust
#16This looks great. I might be giving this a shot for a use case we have. My main concern is the docs.rs-generated documentation is hard to use. I don't exactly know how things fit together. I'm sure I could figure it out via tests, but more docs and usage examples would help a lot.
As for your search for SWIM in the Rust ecosystem: I found a pretty good (well documented and tested) crate: https://crates.io/crates/foca
Re: Decentralized cluster membership in Rust
#17This looks great. I might be giving this a shot for a use case we have. My main concern is the docs.rs-generated documentation is hard to use. I don't exactly know how things fit together. I'm sure I could figure it out via tests, but more docs and usage examples would help a lot. As for your search for SWIM in the Rust ecosystem: I found a pretty good (well documented and tested) crate: https://crates.io/crates/foca
Thanks a lot, you can always file a issue on https://github.com/quickwit-oss/chitchat. We can improve the documentation, add more example and mostly learn from your use case.
Re: Decentralized cluster membership in Rust
#18Is this related to [Secure] Scuttlebutt (SSB), or just using the same name?
No it's not.
Re: Decentralized cluster membership in Rust
#19Is this related to [Secure] Scuttlebutt (SSB), or just using the same name?
Unfortunately, there exist two different distributed protocols named scuttlebutt. The one referenced here is a gossip algorithm, the one you mention is a social network protocol.
They appeal to different enough spheres and scuttlebutt is such a good name I can't fault whoever moved second on that one.
Re: Decentralized cluster membership in Rust
#20[deleted]