4 ms·
I wish people who write these posts would tell us, the RobustIRC authors, about it, and would ask us for proof-reading. > For the entire duration of the partit
by secure 11y ago
I wish people who write these posts would tell us, the RobustIRC authors, about it, and would ask us for proof-reading.
> For the entire duration of the partition, users on the smaller half will be paralyzed
No. RobustIRC nodes that are not part of the majority will cancel long-running GetMessages requests and refuse any other requests. The client will switch to a different node.
This is even mentioned as a possibility in a later paragraph:
> I’ll leave the reader to think through some scenarios, such as establishing a temporary domain of consensus on the smaller half, or forcing users to reconnect to the larger half.
Given this piece of information, I’m not sure what the article’s point really is. At least for the current deployments, the RobustIRC design works well in practice. Sure, strictly speaking, RobustIRC cannot _entirely_ eliminate unavailability (nothing can), but in practice you can work around unavailability really well.
- aji 11y agoI'll admit that there's a lot of gaps in my knowledge of how RobustIRC works, I tried to make that clear in the post. I was just enumerating the obvious problems with using strong consistency with IRC, RobustIRC being the most prominent implementation, and explaining how working around those problems ultimately leads to something only marginally better than what IRC currently is. (I apologize for the admittedly sensationalist title.)
- secure 11y agoI totally agree that RobustIRC is only marginally better than IRC, but that’s exactly what we were going for. We wanted to have IRC, just without these annoying netsplits :).