RobustIRC | Hacker News Reader

RobustIRC

robustirc.net

41 pointschei0aiV11 comments

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

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.

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.)

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 :).

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?

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.

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.

It took me a while to actually figure out what this does. There's no clear "how does this thing work" documentation without diving into the RobustIRC protocol.

Did you read http://robustirc.net/docs/adminguide.html? I thought it has a good description of what RobustIRC does.

There’s also a presentation and presentation slides on http://robustirc.net/docs.html

If you have a suggestion as to how to make it more clear/more succinct (?) what RobustIRC is, I’d be happy to hear it and improve the documentation.

But what if robustirc goes down? :P

Then there's the systemd-provided socket which buffers any request while systemd's watchdog restarts the service. In the meanwhile systemd writes a coredump to the journal to which later gdb can be easily attached by running 'coredumpctl gdb $(which robustircd)'.

Reply on news.ycombinator.com