6 ms·

https://medium.com/@aji/robustirc-is-a-regression-a1e9b6c966c5#.ug8r834u2 https://medium.com/@aji/robustirc-is-a-regression-a1e9b6c966... - "RobustIRC is a regr

https://medium.com/@aji/robustirc-is-a-regression-a1e9b6c966c5#.ug8r834u2 https://medium.com/@aji/robustirc-is-a-regression-a1e9b6c966... - "RobustIRC is a regression"

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 ago
  I'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 ago
    I 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 :).
rix0r 11y ago
Given a consensus protocol, it should be easy to connect the servers in a mesh though, right, getting rid of the tree structure and the single links?
- secure 11y ago
  You’re correct in that there is no tree structure in RobustIRC. All nodes talk directly to each other. Raft dictates a topology where the leader must be able to reach all followers directly, though.
Merovius 11y ago
The article has the basic underlying (though not explicitly written down) assumption, that an AP IRC network (like the classical IRC) is strictly superior to a CP IRC network (like RobustIRC). But that's not a universal fact, but merely a matter of opinion. And no one claims, that RobustIRC is AP. It will survive most netsplits without real problems, but of course, if the network splits such that you as a user can't reach any of the serves in the majority partition, you can't participate. But a) this isn't very probable, unless b) you can reach no server at all (in which case, obviously, regular IRC also fails). You might even claim, that the fact that RobustIRC includes the user as a part of the "network" (by not relying on a single identifying TCP connection, but instead offering carrying over a session to a different server) it handles most netsplits better then traditional IRC (because it has less user impact). tl;dr: RobustIRC makes the conscious choice to sacrifice some availability for consistency. But even then, it can still be available through most netsplits.

https://medium.com/@aji/robustirc-is-a-regression-a1e9b6c966c5#.ug8r834u2 https://medium.com/@aji/robustirc-is-a-regression-a1e9b6c966... - "RobustIRC is a regression"

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 ago
I'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 ago
  I 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 :).

rix0r 11y ago

Given a consensus protocol, it should be easy to connect the servers in a mesh though, right, getting rid of the tree structure and the single links?

secure 11y ago
You’re correct in that there is no tree structure in RobustIRC. All nodes talk directly to each other. Raft dictates a topology where the leader must be able to reach all followers directly, though.

Merovius 11y ago

The article has the basic underlying (though not explicitly written down) assumption, that an AP IRC network (like the classical IRC) is strictly superior to a CP IRC network (like RobustIRC). But that's not a universal fact, but merely a matter of opinion. And no one claims, that RobustIRC is AP. It will survive most netsplits without real problems, but of course, if the network splits such that you as a user can't reach any of the serves in the majority partition, you can't participate. But a) this isn't very probable, unless b) you can reach no server at all (in which case, obviously, regular IRC also fails). You might even claim, that the fact that RobustIRC includes the user as a part of the "network" (by not relying on a single identifying TCP connection, but instead offering carrying over a session to a different server) it handles most netsplits better then traditional IRC (because it has less user impact). tl;dr: RobustIRC makes the conscious choice to sacrifice some availability for consistency. But even then, it can still be available through most netsplits.