RobustIRC

or: IRC without Netsplits

Axel Wagner, Michael Stapelberg

Outline

• motivation
• overview
• RobustSession protocol
• raft
• fine print
• conclusion

Background

• IRC = Internet Relay Chat
• RFC1459, RFC281x, …

Motivation

• IRC is wide-spread in some circles
• there is no convincing alternative
• IRC has poor stability
• TCP disconnects split the IRC network
• software updates, reboots, … split the network
• how can we prevent netsplits, staying compat.?

Idea

• handle TCP disconnects transparently
• there are highly reliable databases, so:
• distribute the IRC server across multiple servers
• input / output model dictated by Raft/Paxos

Overview

• n RobustIRC servers make up 1 virtual IRC server
• minority of servers (≤ floor(ⁿ⁄2)) may fail
• 3 servers: 1 can fail. 5 servers: 2 can fail
• RobustSession protocol for client↔server
• “bridge” translates IRC to RobustSession
• runs on the same machine as the IRC client
• in the future: plugins/native support in IRC clients?

Overview (communication architecture)

IRC client 1

IRC client 2

IRC client n

…

bridge 1

bridge 2

bridge m

…

IRC

RobustIRC

IRC over

RobustSession

RobustSession protocol

• HTTP+JSON instead of pure TCP connections
• 4 methods: CREATE, POST, GET, DELETE
• correspond to connect, send, receive, disconnect
• retry for sending messages (duplicates filtered)
• resume for receiving messages
• each server can handle any method
• possibly by reverse-proxying to the current leader

Raft

„Raft is a consensus algorithm […] It was meant to be more understandable than Paxos […], but it is also formally proven safe and offers some new features.

​

Raft offers a generic way to distribute a state machine across a cluster of computing systems, ensuring that each node in the cluster agrees upon the same series of state transitions.“

• http://en.wikipedia.org/wiki/Raft_(computer_science)
• http://raftconsensus.github.io/
• http://thesecretlivesofdata.com/raft/ (interaktive Visualisierung)

Raft (briefly)

Raft network

A

C

B

Client

6ms

8ms

Raft (usage)

• we replicate IRC input messages via raft
• IRC output messages depend only on the input

→ each server computes the same state�→ same state will be generated after a replay

Overview (data processing)

POST message

client

replicate to

leader

ircServer.Process

leader

OutputStream

GET messages

client(s)

followers

leader

followers

1

2

3

(quorum)

(rest)

e.g. “JOIN #i3”

e.g. “:stapelberg JOIN #i3”

Deletion of old messages

• IRC messages retained forever by default�→ privacy problem, storage problem
• periodic cleanup (“compaction”) on each node

NICK sECuRE_

JOIN #i3

NICK sECuRE

PRIVMSG #i3 :hey

NICK sECuRE_

JOIN #i3

NICK sECuRE

PRIVMSG #i3 :hey

Deletion of old messages(2)

NICK sECuRE_

JOIN #i3

TOPIC #i3 :ohai

NICK sECuRE

NICK sECuRE_

JOIN #i3

TOPIC #i3 :ohai

NICK sECuRE

:robustirc.net 332 mero #i3 :ohai

:robustirc.net 333 mero #i3 sECuRE_ 1422312312

Deletion of old messages(3)

NICK sECuRE_

JOIN #i3

TOPIC #i3 :ohai

NICK sECuRE

TOPIC #i3 :bye

NICK sECuRE_

JOIN #i3

TOPIC #i3 :ohai

NICK sECuRE

TOPIC #i3 :bye

fine print

• speed limited by server network
• latency = median leader↔follower latency
• resilience requires at least 3 failure domains
• fewer failure domains are okay, but offer less resilience (e.g. only against hardware failures)
• too little throughput for very big networks?
• 1000+ messages/s at the moment (plans for more)

conclusion

• help us testing, give us feedback!
• http://robustirc.net
• setting up the bridge (requires Go):
• export GOPATH=~/gocode
• go get github.com/robustirc/bridge/robustirc-bridge
• $GOPATH/bin/robustirc-bridge -network=robustirc.net
• Connect to localhost:6667 in your IRC client

Demo

Demo!