 Dann herzlich willkommen! Danke, dass ihr da seid. Der Titel dieses Vortrages lautet RobustIRC oder IRC ohne NetSplits. Zunächst zum Überblick über den Vortrag. Ich werde erstmal motivieren, warum wir überhaupt einen Projekt angefangen haben, was sich mit IRC befasst. Dann werde ich einen Überblick darüber geben, wie RobustIRC funktioniert und was unsere grundsätzlichen Ideen sind. Ich werde ganz kurz auf das Robust Session Protokoll eingehen, dann auf RAVT, was die zugrunde liegende Technologie ist. Ich werde das Kleingedruckte euch nicht vorenthalten und danach über die Lektionen, die wir aus dem Betrieb eines Netzes über mehr als ein Jahr mittlerweile gelernt haben, vorstellen. Zunächst zum Hintergrund. IRC steht, wie die allermeisten von euch wissen, für Internet Relay Chat und wurde in RFC 1459 und ein paar Nachfolge RFCs standardisiert, sag ich mal. Wer sich schon eingehen mit dem IRC befasst hat, weiß, dass es viele Eigenentwicklungen, Eigenimplementationen gibt, was sowohl die Kleint- als auch die Serverseite angeht. Es gibt also eine ganze Reihe an verschiedenen Coach-Trennen sozusagen. Es gibt ganz viele verschiedene IRC-Server und alle haben so ein bisschen ein anderes Verständnis von dem bestehenden Standard und haben so ein bisschen eigene Funktionen, die sie mit eingebracht haben. Es gibt, wie auf der Folie zu sehen, links unten abgebildet habe ich XChat, ein sehr beliebtes Unix Chat-Programm, welches IRC unterstützt und auf der rechten Seite sieht man ein Mobilfunktelefon, welches auch ein IRC-Kleint hat. Also es gibt quasi für jede erdenkliche Plattform IRC-Kleins. Ganz kurze Publikumsbefragung, wer von euch ist in irgendeiner Art und Weise zumindest manchmal im IRC, bitte die Hand heben? Das sind so ziemlich alle, bis vielleicht auf einen. Dann erzähle ich euch damit ja nichts Neues. Ich möchte trotzdem noch kurz motivieren, warum wir robust IRC geschrieben haben. Das IRC ist in einigen Kreisen, wie hier in diesem Raum eben auch, weit verbreitet. Insbesondere ist das die freie Softwarekultur oder eben die Hacker-Community. Dort läuft sehr viel über IRC. Immer mal wieder packt es uns dann und mit uns meine ich den lokalen Chaos-Treff damals in Heidelberg noch und wir schauen uns dann an, so was gibt es eigentlich für Alternativen zu IRC, weil wir nicht so super zufrieden sind mit IRC und immer mal wieder schauen wir uns dann so um und evaluieren so die anderen Sachen, so das was sich innerhalb des letzten Jahres oder so etabliert hat oder was versucht sich zu etablieren und dann finden wir immer nichts von dem überzeugt uns wirklich und dann bleiben wir doch immer noch im IRC, weil das ist ja schon eingerichtet uns läuft bei allen und Keins hat so genug Pull um uns dazu zu bewegen zu wechseln und dann haben wir uns aber überlegt was ist eigentlich das was uns am allermeisten stört am IRC und für uns persönlich kam dann die Stabilität als großer Punkt. Die ist verbesserungswürdig finden wir und das grundlegende Problem ist, dass TCP Verbindungsabbrüche das Netz zerteilen und das passiert sowohl zwischen dem Client und dem Server, also wenn ich mich mit meinem Computer jetzt in den Netz verbinde und die TCP Verbindung abreist, weil ich gerade im Rundlaufe und das WLAN abreist, dann kann ich nicht mehr an dem Chat teilnehmen. Soweit so gut, das erwartet man ja auch gegebenenfalls. Jetzt ist aber so, dass ein TCP Verbindungsabbruch zwischen der Verbindung zwischen zwei Servern in einem Netz das komplette Netz zerteilt. Dadurch können dann also die Leute, die mit dem einen Server verbunden sind, nicht mehr mit den Leuten reden, die auf dem anderen Server verbunden sind. Das heißt, ein TCP Verbindungsabbruch ist invasiv und daraus folgen verschiedene Andreize, die man als Betreiber eines IRC-Netzes oder eines einzelnen IRC-Servers hat. Das bedeutet also, wenn ich als Betreiber von einem IRC-Server meine Software aktualisieren will, dann bin ich angehalten, dass so selten wie möglich zu tun, weil wenn ich einen neuen Kernel installiere und dann rebooten muss, dann sind ja alle TCP Verbindungen getrennt und dann mache ich quasi das Netz so ein bisschen kaputt und je kürzer das dauert, desto glücklicher sind meine Nutzer. Und das finde ich heutzutage umso mehr fragwürdig. Also früher auch schon, aber heute umso mehr, weil wir quasi jede zweite Woche eine Sicherheitslücke haben in irgendeiner Library, in irgendeinem Subsystem von der Software, die wir benutzen und dann muss man aktualisieren. Das heißt, entweder hat man ein gutes IRC-Netz und schlechte Software, schlechte Security, eine hohe Angriffswahrscheinlichkeit, einen hohen Angriffsvektor oder man ist topaktuell und die Nutzer mögen einen nicht, weil andauernd die Verbindungen kaputtgehen. Und das fand ich doof. Und dann haben wir uns überlegt, wie könnte man denn eigentlich Netzblitz verhindern, aber kompatibel bleiben mit IRC, also mit der bestehenden Client-Landschaft. Wir haben dann eine zweigeteilte Idee entwickelt. Die eine Idee ist, dass TCP Verbindungsabbrüche einfach transparent gehandhabt werden soll. Also eine TCP Verbindungsabbruch zwischen Client und Server soll einfach kein Problem mehr sein. Und die Lösung dafür ist, dass Robust-Session-Protokoll, was ich gleich noch vorstellen werde. Und der andere Teil der Idee ist, auch zwischen den Servern sollen Verbindungsabbrüche kein Problem mehr sein. Und vor allem aber auch Neustarts sollen kein Problem mehr sein. Also wenn ein Server aus irgendwelchen Gründen nicht mehr verfügbar ist, dann darf das gar nicht auffallen im Normalbetrieb von dem Netz. Und wir haben uns dann umgeschaut und festgestellt, es gibt hoch verfügbare Datenbanken. In den Folien habe ich da einen Link reingepackt und dann haben wir uns überlegt, warum nehmen wir nicht einen IAC-Server und implementieren einen IAC-Server auf Basis von einer Library wie RAVT oder PAXOS, dazu gleich noch mehr und verteilen damit einen IAC-Server als verteiltes System auf mehrere Server. Und von denen darf dann einer oder mehrere ausfallen. Als Überblick also, man hat eine bestimmte Anzahl an Robust-IRC-Servern, ich sage mal N-Server, die dann einen virtuellen IAC-Server bilden. Das heißt, bei Robust-IRC hat man nicht einen Netz, was aus mehreren Servern besteht, sondern man hat beliebig viele Server, aber wie viele man tatsächlich hat, ist ein Implementationsdetail, was einen als Anwender gar nicht interessiert. Für mich sieht es immer so aus, als würde ich mich mit einem IAC-Server verbinden. Wenn man jetzt also drei Server betreibt, dann ist ein Ausfall der Minderheit an Knoten immer okay. Das heißt, bei drei Servern darf einer ausfallen, bei fünf Servern dürfen zwei ausfallen und so weiter. Man kann das also nach oben skalieren. Es ist allerdings auch so, dass man nicht beliebig viele Server in so einem Netz packen will, weil dann der Overhead eben auch mitwächst. Das heißt, es gibt quasi so ein Sweetspot, wir betreiben zum Beispiel unser offizielles Netz, also offiziell, weil es eben auf dem Domain namen Robust-IRC.net läuft mit drei Servern und das funktioniert für uns gut. Es ist aber auch denkbar, dass man eins mit fünf Servern betreibt oder in anderen Konstellationen. Wie gesagt, das Robust-Session-Protokoll wird benutzt zwischen Server und Clients. Und dann haben wir ein kleines Programm namens Bridge. Das kann man sich so vorstellen wie ein Proxy-Server, der läuft üblicherweise auf demselben Rechner wie der IRC-Client und der nimmt dann den IRC-Traffic entgegen, verpackt ihn in Robust-Session und schickt ihn dann zum Server. Es gibt auch für bestimmte IRC-Clients, im Moment ist das nur für IRC, gibt es einen Plug-in, mit dem man das direkt sprechen kann, ohne dass man zusätzliche Software installieren muss auf seinem Computer. Und zukünftig könnte man vielleicht über nativen Support in Clients nachdenken, mal sehen. Das Robust-Session-Protokoll benutzt HTTP und JSON statt puren TCP-Verbindungen. Die Wahl fiel auf HTTP und JSON, weil das sehr, sehr weit verbreitete Technologien sind, die in quasi jeder Programmiersprache ganz einfach zur Verfügung stehen. Das heißt, egal wie euer Client aussieht, ihr könnt mit Sicherheit Robust-IRC benutzen, direkt, also man kann den Plug-in implementieren oder nativen Support. Das war die Wahlen. Außerdem ist es sehr freundlich zu Debuggen und für Corporate Firewalls und für solche Umgebungen. Die vier Sachen, die man mit TCP-Verbindungen machen kann, also Connect-Verbindungen aufbauen, Disconnect-Verbindungen wieder trennen, senden und empfangen, haben wir abgebildet auf vier verschiedene Anfragen über HTTP. Der Connect ist ein Post auf Slash Create, das Senden ist ein Post auf Slash Message, das Get ist ein Get Slash Message und Delete ist dann eben um die Session wieder zu löschen. Für den Nachrichtenversand, also für den Post-Request, den man schickt, den kann man wiederholen, weil der eine Unique ID eingebaut hat und wenn der Server bemerkt, dass er eine Nachricht nochmal bekommt, dann sagt er einfach, ist okay, ich habe die jetzt bekommen. Filtert aber Duplikate raus. Das heißt, der Client, wenn er sich nicht sicher ist, ob der Server die Nachricht gesehen hat, weil er vielleicht nur die Anfrage geschickt hat, aber die Antwort noch nicht bekommen hat, wenn dann Verbindungsabdruck in der Mitte war, kann sich darauf verlassen, dass er einfach so häufig, wie er möchte, dieselbe Nachricht schicken kann, solange eben die Unique ID gleich ist und dann wird der Server da schon das Richtige tun. Für das Empfang von Nachrichten funktioniert das ganz ähnlich. Es gibt eine Resume Funktionalität, das heißt, man kann dem Server sagen, das war die letzte Nachricht, die ich gesehen habe und der Server schickt einem dann alle folgende Nachrichten. Zusätzlich ist es so, dass jeder Server jede Anfrage beantworten kann. Das heißt, wenn man ein partielles Netzproblem hat, zum Beispiel ich kann bei meinem Internetanbieter nicht mehr mit einem der Server reden, weil irgendein Peering kaputt gegangen ist oder sowas, dann kann ich immer noch an den anderen Server schicken und gegebenenfalls, wenn er muss, leitet der dann die Nachricht für mich weiter, weil die Server untereinander ja in Kontakt stehen müssen, aber zum Beispiel für passive Sachen, wie zum Beispiel das Empfang von Nachrichten, handhabt der Server das dann direkt und kann mir direkt die Antwort geben. Ich habe jetzt schon erwähnt, dass wir Raft benutzen und ich zitiere einfach mal die Definition von Raft von Wikipedia und danach schauen wir uns noch kurz an. Auf Wikipedia steht Raft is a consensus algorithm. It was meant to be more understandable than Paxos, but is also formally proven safe and offer 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. Es gibt da unten, da habe ich noch ein paar links auf die Folie gepackt, da gibt es supervisualisierungen davon, wie Raft tatsächlich funktioniert, falls euch das on-detail interessiert. Schauen wir uns mal die Kurzfassung an davon. Angenommen, wir haben hier drei Server, repräsentiert durch die Knoten A, B und C. Der Knoten A in grün markiert ist der sogenannte Leader und B und C sind die Follower. Diese Knoten bilden dann zusammen genommen ein Raft Network. Der Kleint schickt jetzt seine Nachricht an das Raft Netz. Das heißt, konkret erspricht mit dem Knoten, der momentan der Leader ist, das wäre also A. Und A schickt dann die Nachricht an B und an C weiter. In diesem Beispiel gehen wir jetzt davon aus, dass die Netzwerklatenz zwischen A und B sechs Millisekunden beträgt und zwischen A und C acht Millisekunden. Bei Raft ist es so, dass eine Nachricht als persistiert und angenommen gilt, sobald sie auf der Mehrheit der Knoten angekommen ist und auf die Festplatte gespeichert wurde. Das heißt, in diesem Beispiel mit den drei Knoten nimmt A die Nachricht an, schreibt sie auf die Festplatte, schickt sie an B und dann C, kriegt von B das OK zurück ein klein bisschen schneller als von C und sagt zu dem Zeitpunkt dann schon dem Kleinen, ja, die Nachricht habe ich jetzt bekommen. Und dann kann sie verarbeitet werden. Bis das passiert ist, wird eine Nachricht nämlich noch nicht verarbeitet. Deswegen bleibt auch alles konsistent. Und C kriegt dann die Nachricht auch früher oder später. Das ist aber nicht so wichtig. Wie wenden wir jetzt das, wie wenden wir Raft an? Wir replizieren einfach alle IRC Nachrichten. Also alles, was reinkommt, alles, was die Kleins uns schicken, replizieren wir über Raft. Und die Antworten hängen nur von den Nachrichten an sich ab. Das heißt, wir haben einfach eine State Machine implementiert. Also wir haben den IRC Server als State Machine implementiert und jeder Server generiert, wenn er die gleiche Eingabe hat, auch immer die gleiche Ausgabe. Das erlaubt uns, dass wir Server beliebig neu starten können. Wir können Server abstürzen lassen und sie dann wieder neu starten. Wir können sie absichtlich rebooten und so weiter. Wir können Server austauschen. Es alles egal. Am Ende, wenn die Server dann wieder gestartet sind, sind sie wieder in genau dem gleichen Zustand wie alle anderen Server in diesem Netz. Das Kleingedruckte dazu, die Latents, also wie schnell eine Nachricht, die ich jetzt zum Beispiel schicke, bei anderen Leuten, die in demselben Channel sind, ankommt, ist dadurch limitiert, wie gut die Verbindungen der Server untereinander sind. Also mal abgesehen natürlich von den Verbindungen zwischen dem Kleint und dem Server an sich. Davon ist sie immer limitiert. Aber bei uns, wie ich gerade erklärt habe, wird eine Nachricht, die reinkommt, ja erst mal von Raft auf die Mehrheit der Knoten verteilt und erst dann wird sie verarbeitet. Das heißt, die Medienlatents zwischen Lieder und Followern ist genau die Latents der Nachricht mindestens. Weiterhin ist es so, dass wenn man komplett perfekte Ausfallsicherheit haben will, dann braucht man dafür natürlich auch mindestens drei Failure Domains, wenn man eben drei verschiedene Knoten betreibt. Das heißt, wenn ich einen Setup haben will mit perfekter Ausfallsicherheit, dann müsste ich eigentlich dafür sorgen, dass ich drei verschiedene Rechenzentren habe, indem drei verschiedene Netzanbieter mir meine Bandbreite liefern, mit drei verschiedenen Stromanbietern und so weiter. Also ich müsste quasi bei einem Anbieter einen Knoten haben, bei einem ganz anderen Anbieter, ganz woanders in anderen Knoten und genau so haben wir das Netz tatsächlich auch aufgezogen. Jetzt ist es so, das ist vielleicht nicht immer machbar. Vielleicht haben Leute irgendwie zum Beispiel Firmen intern, möchten sie das in ihrem Rechenzentrum hausen. Dann muss man sich natürlich genau überlegen, wie man die verschiedene Knoten verteilt. Wenn man zum Beispiel alle drei Robustiracy Knoten auf dieselbe VM legt und die VM dann ein Problem hat, dann sind natürlich alle drei weg. Das ist soweit klar, denke ich. Man musste also genau drauf schauen. Dann das letzte Kleingedruckte, also das letzte Problem ist, dass der Durchsatz von Robustiracy vielleicht noch nicht hoch genug ist für die allergrößten Netze. Das heißt, solche Netze wie Freenote oder QuakeNet, die haben mehr Nachrichten pro Sekunde, als wir derzeit verarbeiten können. Der letzte Benchmark, den ich gemacht habe, hat ergeben, dass wir ca. 1000 Nachrichten pro Sekunde verarbeiten können. Was schon eine ganze Menge ist für ein IEC-Netz, aber bei großen Netzen gibt es eben deutlich mehr. Und wir haben dafür aber eine Idee, die ist allerdings momentan noch nicht umgesetzt, denn in unserem Netz befinden sich zwischen 50 und 100 Nutzer und dann braucht man auch nicht hochoptimieren für Netze, deren Anwendungsfall man gar nicht hat. So, jetzt können wir mal eine kurze Demo machen. Es gibt ein Tool, das nennt sich LocalNet. Das ist so ein kleines Rapper-Skript, welches dafür sorgt, dass man ein gültiges Zertifikat hat, dass es eine Voraussetzung ist für den robust IEC-Netz und dann die verschiedenen Prozesse startet, alles auf dem lokalen Computer, einfach damit man ein bisschen mit rumspielen kann beim entwickeln. Und wir können uns dann auch noch das Monitoring anschauen, das stelle ich aber erst mal hinten an, damit wir schön in der Zeit bleiben. So, ich bin also hier in meinem robust IEC-Directory und es gibt hier robust IEC-LocalNet. Da kann ich angeben. Der Start Moment kurz. Moment, für stopp brauche ich das vielleicht, für start brauche ich es nicht. Probieren einfach mal aus, was passiert. Er sagt jetzt starting und dann ging das ganz flott, da kamen dann noch 2 Knoten hinterher. Was er jetzt hier auf den Bildschirm wirft, ist die Adresse des ersten Knotens und auch aller folgenden Knoten. Und man sieht hier, er startet den ersten Knoten, sagt nach einer Weile okay, das ist jetzt der Lieder geworden und dann startet er die anderen Knoten, die dann in das Netz dazukommen. Wir können jetzt in einem beliebigen Browser einmal auf diese Startseite gehen und sehen dann, dass der erste Knoten, der hier gestartet wurde, tatsächlich im Zustand Lieder ist und hier sind die Adressen der verbleibenden Knoten, dann gibt es ein paar Statistiken über RAVT, also die RAVT Library uns gibt und dann sehen wir hier, es gibt das Netz ja gerade erst gestartet haben und in dem Log, also in allen Einträgen, die über RAVT persistiert wurden und verarbeitet werden, gibt es derzeit nur die allererste Nachricht, die das LocalNet Tool für uns eingibt, wo ein Dummy Passwort und Erg Operator definiert wurde, einfach damit man schneller testen kann. Soweit so gut, jetzt kann ich hier einen ERC-Klein starten und kann sagen, Connect Localhost und dann sehe ich, dass ich hier mich mit dem ERC-Net verbunden habe, sagt hier welcome to robust ERC und jetzt kann ich hier zum Beispiel in einen Channel gehen und dann sieht man okay, ich joine diesen Channel soweit so gut, wenn ich was schreibe, dann kommt das hier an. Wir können nochmal auf die Startesseite gehen, hier hat sich das jetzt verändert, wir sehen die Session wurde, wird jetzt angezeigt, Get Message Request gibt es keine auf dem Knoten, der ist dann wahrscheinlich irgendwo anders hingegangen, wie vorhin erwähnt ist es ja egal, welcher Server den Get Message Request bekommt, die können alle beantworten und hier sehen wir jetzt die Entträge, die reinkamen, man sieht hier die klassischen Nick User Messages, die der ERC-Klein benutzt, um sich zu verbinden, dann das Join-Demo usw. Wichtig ist hier noch zu bedenken, die Nachricht, die ich gerade geschickt habe, wurde ausgefiltert, weil es hier natürlich nicht darum geht, die Nutzer auszuspionieren, sondern das wird hier angezeigt aus Debugging-Runden. So, jetzt starte ich mal noch einen zweiten ERC-Klein, verbinde mich auch mit dem Lokalnetz, gehe auch in den Channel, kurz hallo, wir schauen auf der anderen Seite. Hier dauert es jetzt eine kurze Sekunde, bis das auftaucht, weil ich üblicherweise, wenn ich mich mit einem ERC-Netz verbinde, in die Flat-Protection laufe, also meine Nachrichten werden dann einfach ein bisschen langsamer verarbeitet, das ist aber im Normalbetrieb gar kein Problem. Wenn ich jetzt also hier antworte, dann sieht man, die kam sofort an. Und was wir jetzt mal machen können, ist, wir können uns jetzt einfach einen Knoten schnappen und den stoppen. Ich kann also hier mal kurz schauen, ich habe robust ERC-Prozesse auf meinem Computer laufen. Wenn wir von oben nach unten durchgehen, sieht man hier zunächst mal den ersten Knoten, dann hier den zweiten Knoten, das nächste der dritte Knoten und dann sieht man die Bridge, die ich hier im Laufen habe. So, jetzt nehmen wir doch einfach mal den allerersten Knoten, das ist glaube ich am spannendsten, weil das ja derzeit der Lieder ist. Und dann schauen wir mal, wie sich das System verhält, wenn wir den jetzt einfach abschießen. Wir schauen also hier oben nochmal kurz, und dann machen wir auch nochmal kurz hier die Status-Seite auf von einem anderen Knoten, damit wir dann gleich weiter schauen können, wie sich das Netz verhält. Genau, also der zweite Knoten hier ist jetzt derzeit im Zustand Follow. Jetzt, da habe ich die Process ID abgeschnitten, das sollte die hier werden, den killen wir. Jetzt schauen wir auf die erste Status-Seite, die ist jetzt weg, der Knoten ist jetzt tot. Im zweiten sehen wir, der ist jetzt in den State Candidate gegangen. Das bedeutet, der hat jetzt realisiert, oh, da kam gar keine Healthchecks in einem bestimmten Zeitrahmen, das Timeout ist standortmäßig 2 Sekunden, und dann sagt er, okay, dann müssen wir jetzt wohl unter uns ausmachen, wer der neue Lieder werden soll. Und wenn ich jetzt nochmal refreshe, sieht man, okay, der ist jetzt der Lieder geworden. Hätte auch der andere Knoten werden können, das ist nicht deterministisch, also nicht deterministisch in dem Sinne der E-Request war von Anfang an auf dem zweiten Knoten, der musste also nirgendwo anders hin. Man sieht auch die Sessions und das Log soweit so gut, wir können jetzt mal kurz in die IAC Clients schauen. Wie man hier sieht, hat sich nichts getan, wenn ich hier was schreibe, kommt es hier immer noch an, also den einen Knoten abzuschießen, ist komplett egal gewesen für die ganzen IAC Clients. Jetzt fragt sich vielleicht so mancher, was passiert denn jetzt, wenn wir noch einen Knoten abschießen? Weil da ist ja jetzt nichts mehr garantiert eigentlich, die Minderheit der Knoten kann sterben für drei Server, also einer. Einer ist jetzt weg, aber was passiert, wenn wir noch einer abschießen? Jetzt nehmen wir einfach mal den hier, sagen Kill, und der ist jetzt weg, soweit so gut. Jetzt schreiben wir hier was und das kommt jetzt hier nicht an. Okay, soweit, vielleicht noch erwartet. Jetzt können wir mal schauen, was passiert, wenn ich jetzt hier in dieses Verzeichnis gehe, hier gibt es so einen Restart Skript, welches den Knoten einfach wieder startet und der ist jetzt wieder da, der ist jetzt Follower geworden, das heißt, der dritte Knoten ist jetzt der Lieder und in den IAC Clients sieht man jetzt auch, dass die Nachricht, die ich hier geschickt habe, hier mittlerweile angekommen ist. Das heißt, was passiert, wenn zu viele Knoten sterben, ist das Netz friert ein sozusagen und fängt sich dann aber wieder, soweit der Knoten wieder dazukommt. So, gut. Mit dem Monitoring schauen wir später, wenn wir noch Zeit haben und jetzt zunächst noch über die Sachen, die wir gelernt haben. Ich denke am wichtigsten ist, dass die Nutzer nur sehr, sehr zögerlich ihr IAC Setup ändern, was sie einmal eingerichtet haben. Bei uns setzen sich die Nutzerzahlen derzeit zusammen aus 50%-Nutzern, die eine Bridge benutzen, die wir für sie betreiben, die nennen wir Legacy RC, weil das eben eine Bridge ist, die immer noch Probleme hat, das heißt, auf unseren 3 Servern, die wir betreiben, haben wir auch jeweils eine Bridge am Laufen, auf die sich Nutzer direkt verbinden können, die an ihrem System nichts ändern wollen. Das heißt, die stellen einfach einen anderen Servernamen ein oder einen neuen Server und verbinden sich soweit so gut. Das Problem ist natürlich, wenn die Verbindung zwischen dem Nutzer und der Bridge, die bei uns läuft, kaputt geht, fliegen die natürlich raus. Da können wir nichts gegenmachen. Die Bridge muss nämlich so nah wie möglich beim Nutzer laufen, mit dem selben Computer oder am besten gar keine Bridge, sondern dass die Software der ERC-Client selber das Robustation-Protokoll sprechen kann. 49% unserer Nutzer betreiben selber eine Bridge, soweit so gut, und 1% unserer Nutzer benutzt das ERC-Plugin. Das funktioniert aber für mich. Die zweite Punkt, den wir gelernt haben, ist, dass einige Bugs für Laien ganz ähnlich aussehen wie ein Netzblit. Wir hatten tatsächlich in den ersten paar Monaten, wir haben ein paar Sachen noch gefunden, die wir übersehen haben beim Programmieren, wie das immer so ist, und immer wenn so etwas passiert ist, also immer wenn es so einen Bug gab, dann kamen danach Leute und kamen in den Channel und haben gesagt, was ist denn da los? Wir haben jetzt doch Robust ERC. Die Idee war doch, dass wir keine Netzblitz mehr haben und trotzdem gab es vorhin einen Split. Und dann muss man immer genau hinschauen und schauen, warum sind die jetzt rausgeflogen, was war da das Problem? Das war ein Server, den ich absichtlich rebooted hatte. Bei dem sich dann herausstellte, dass die Hardware-Clock mit der Software-Clock nicht konform geht, also die war falsch konfiguriert. Das heißt, nachdem der dann rebooted war, kam er zurück mit einer Zeitabweichung von genau einer Stunde. Da war also die Zeitzone oder Daylight-Saving-Time nicht korrekt. Und das ist zunächst mal kein Problem. Der ist dann also in das Netz wieder eingefügt worden, dann ging erst mal alles weiter. Irgendwann wurde dieser Server dann der Lieder, den wir persistiert werden, soweit auch noch alles gut. Und nachdem dann aber ein anderer Server Lieder geworden ist und das passiert manchmal, dass einfach ein anderer Server übernimmt, weil es kurze Netzwerkprobleme gibt oder so, das ist gar kein Problem normalerweise. Dann aber stand unser Netz für eine Stunde still. Und die Frage ist, warum? Die Antwort ist, weil die Nachrichten, die wir persistieren, einen Zeitstempel bekommen, der als ID für die Nachricht sorgt. Das heißt, die Server müssen zumindest die Nachrichten nutzen, sie müssen nicht auf die Millisekunde gleichgehen oder so, aber der Unterschied darf nicht zu groß sein. Und in dem Fall war er eben zu groß. Das heißt, der Server hat geschaut, ich bekomme eine neue Nachricht, ich will sie persistieren, ich muss jetzt eine ID bestimmen, hat auf die aktuelle Uhrzeit geschaut und hat festgestellt, Moment, die ID ist kleiner als die andere, weil die andere, die letzte Nachricht eben von dem Server kam, der eine Stunde vorging und hat dann gesagt, die ID kann ich nicht nehmen, das würde sonst Annahmen kaputt machen, und deswegen konnte der dann eine Stunde lang einfach keine IDs finden. Und was dann passiert auf Kleinseite ist, dass die IAC-Cleins eben keine Nachrichten mehr schicken können, wie wir das auch gerade gesehen haben, ich habe eine geschickt und die kamen auf der anderen Seite nicht an und IAC-Cleins schicken aber alle paar Minute oder so eine Ping-Nachricht und erwarten darauf eine Pong-Antwort. Und wenn die dem Ping schicken und keinen Pong bekommen, dann sagen die, oh, da ist offensichtlich irgendwas kaputt, ich beende jetzt die Verbindung und verbinde mich nochmal neu. Und wenn das passiert, dann sieht es für die Nutzer aus wie eine Netzblitz, weil ja man nie erzählt kleint, hat sich die Verbindung getrennt, hat sich neu verbunden, das ist doch, was eine Netzblitz ist, oder? Schränk genommen war das aber nicht so, aber die Grenzen sind natürlich sehr fließend. Also bei Softwarefehlern oder krassen Fehlkonfigurationen, die wir versuchen zu vermeiden, kann es bei RobustRC immer noch Netzblitz geben. Aber in der normalen Operation eben nicht. In dem konkreten Fall haben wir aus dem Fehler gelernt und ein zusätzliches Package eingebaut, namens Time-Save Guard, das schaut eben einfach, bevor es in eine Netz geht, ob die anderen Uhrzeiten mit einem gewissen Toleranzintervall konform gehen oder ob eben so ein Problem auftreten würde und verhindert dann, dass man den Knoten in das Netz packen kann. Und dann wiederum würde das Alerting eben anspringen und sagen, hey, da sind zwei Knoten in einem Netz, in dem eigentlich drei Knoten sein sollten, schau doch mal, was da kaputt ist. So, damit sind wir am Ende des, was ich vorbereitet habe. Wir haben jetzt noch gute fünf Minuten, vielleicht ein bisschen mehr Zeit für allerlei Fragen, die ihr haben könntet. Insofern ihr keine Fragen habt, würde ich die Gegenfrage stellen, würdet ihr robuste RC'n nutzen. Vor allem auch, wenn ihr in ein kleines Netz betreibt oder so, wird es mich sehr interessieren, was denn die Sachen sind, auf die ihr das Augenmerk legt. Also es gibt irgendwas, was vielleicht noch fehlt, bevor ihr es nutzen könntet. Findet ihr es einfach, okay, es ist ein inkrementelles Upgrade, aber nicht wichtig genug, als dass ich meine Server-Software austausche. Oder was ist einfach so eure Meinung? Ich habe hier eine Folie gepackt, das ist die Einrichtungsanleitung, wie man eine eigene Bridge installiert. Man findet das auch auf robusteac.net in genau den gleichen Schritten. Im Wesentlichen, wenn man Go installiert hat, muss man diese Umgebungsvariable setzen, um Go zu sagen, wo der Code hin kommen soll. Dann gibt es einen Befehl, mit dem man sich die Software holt und kompliziert. Dann führt man sie aus und sagt noch, auf welches Netz man sich verbinden möchte und verbindet sich dann im ILC. So, jetzt haben wir Zeit für Fragen. Hier vorne, bitte. Entschuldigung. Mikrofon, bitte. Danke. Kommt die Bridge damit klar, wenn ich zum Beispiel alle 24 Stunden von meinem provaten Neuer Piatresse aufgezogen bekomme? Ja, genau, das ist gar kein Problem. Weil die Bridge bemerkt dann einfach, okay, die Internetverbindung ist kurz weg, verbindet sich dann wieder neu. Alle Nachrichten, die noch nicht gesendet wurden, werden einfach wiederholt und werden vom Netz angenommen. Das ist eben auch genau das Gleiche, was im regulären Netzbetrieb immer wieder passiert. Also, wenn ich zum Beispiel eine neue Software-Version ausrolle, dann bekommt das eigentlich keiner mit. Aber da passiert es nämlich genauso. Ich installiere also eine neue Version von dem RobustRC Executable und stoppe den Server. Der startet dann neu, führt das neue Binary aus und alle Leute, die sich mit diesem Server eben verbunden hatten vorher, werden dann eben disconnected von dem Server. Wer also genau die Situation, hier vorne noch eine Frage? Hi, was ist jetzt der nächste Fokus? Also für die nächste Monate ist es eben diese, wie viel waren es, Tausend Nachrichten, die Sekunde zu erhöhen? Oder wo siehst du die nächste Schritte? Wir haben, also du kannst auch einfach in unseren Bug Tracker schauen, es gibt eine ganze Anzahl an Feature Request, wo wir zuerst mal noch schauen wollen. Also es gibt oft mal so ganz kleine Sachen. Weißt du, so ein kleiner Befehl ist der ISON Befehl, mit dem man nachschauen kann, ob ein anderer Nutzer eingeloggt ist. Den hatten wir am Anfang nicht implementiert, weil keiner unserer Kleinstdien benutzte. Aber dann kam jemand mit einem anderen Klein, der meinte so, hey, ich kriege hier die ganze Zeit Fehlermeldung in meinem Statusfenster, sagt der ISON Command Not Implemented. Solcher Leisachen wollen wir zunächst mal fixen. Dann die Geschichte, mit der Performance-Erhöhung für die Tausend Nachrichten diese Kunde, ist sicherlich interessant, vielleicht aber nicht unbedingt der Fokus. Es gibt noch zwei andere interessante Punkte, die wir so ein bisschen im Auge haben. Das eine ist, wir haben derzeit noch recht wenig Erfahrung beziehungsweise Expertise oder Strategien, wie man damit umgeht, wenn es Angreifer auf das Netz gibt. Also sowas wie DEDOS oder FLUTS oder auch Angreifer, die tatsächlich sich anschauen, wie funktioniert das Protokoll, wie wir in einen besseren DEDOS fahren oder sowas. Da sind wir derzeit einfach unter dem Radar gewesen und das würde mich persönlich interessieren, wie man da den Code ein bisschen robuster machen kann, auch in der Hinsicht, nicht nur in der Hinsicht über Netsplits und Restarts. Und das andere ist ein Feature, was wir Session Resume nennen. Da geht es darum, dass ein großes anderes Problem ist, dass viele Leute eben einen ERC-Kleint Persistent oder dauerhaft auf dem Server betreiben, einfach weil sie nicht ihr Backlog verlieren wollen und weil der Kleint da sein muss, um den Nickname zu halten. Und die Observation ist jetzt, wenn man mal dieses Ping-Pong-Spiel ausblendet, was jede Minute oder so passiert, dann könnte man auch einfach sagen, okay, wenn ich jetzt zum Beispiel meinen Computer hier zuklappe und auf meinem Computer einen ERC-Kleint läuft und ich dann zum Beispiel in ein anderes Land reise und sieben Tage in den Computer nicht aufmachen, dann anmache, warum kann der dann nicht genauso weitermachen wie vorher? Und das ist das, was wir jetzt machen, was wir uns reagieren. Und eigentlich müsste das gehen mit RobusterAC, weil die ganzen Sachen sind schon alle da. Also GetMessages kann Resume und so weiter, jetzt müsste man nur noch schauen, dass man in dem Kleint das Ping-Pong ausschalten kann, was man machen kann, haben wir schon nachgeschaut. Aber das Ganze sozusagen gut verpacken und dokumentieren und testen und so, das wäre funktioniert und jetzt wäre die nächste Frage, kann man Session Resume einbauen? Das wäre natürlich cool. Da hinten gab es noch eine Frage, glaube ich. Diese Bridge, die es da gerade beschrieben ist auf der Folie, ist das auch dieselbe, die er dann betreibt, wenn Leute bei euch direkt... Ganz genau, es ist genau dieselbe Bridge. Was wir allerdings noch machen, was normalerweise nicht nötig ist, ist, wir haben noch ein S-Tunnel vorne dran, damit man sie auch mit SSL benutzen kann. Auf lokalen Installationen hat man sie normalerweise auf Localhost laufen und dann braucht man das nicht. Gibt es noch weitere Fragen? Hier vorne noch. Warum habt ihr euch für Go entschieden? Als Sprache? Warum nicht? Ich habe das Projekt mit einem Freund von mir angefangen und es ist eine unserer Lieblingssprachen. Tatsächlich eignet sich Go eigentlich auch super für solche Sachen, also für Netzwerkdienste, die auf HTTP und JSON basieren und so. Da hast du eigentlich alles, was du brauchst in der Standard Library dran quasi. Und die Raft Library, die wir gefunden haben, war eben auch für Go implementiert und sah ziemlich gut aus. Und dann haben wir einfach gesagt, okay, wir probieren das mal aus, hat sich rausgestellt, das funktioniert ziemlich gut. Es gibt tatsächlich ein paar Pain Points, die sind es nicht mit der Sprache an sich, sondern eher mit der Implementation in der Standard Library. Es stellte sich zum Beispiel raus, dass die Geschichte mit dem 1000 Messages pro Sekunde. Das Bottleneck war zumindest damals, oder so, und 1.6 ist aktuell, also es ist schon ein Jahr her oder so was. War das Problem hauptsächlich das Krypto-Slash-TLS-Package. Das war einfach nicht optimiert genug. Das benutzte zum Beispiel damals keine Assembler-optimierten Instruktionen, also die AIS-Extension auf modernen Intl.Cipius zum Beispiel. Mittlerweile in Go 1.6 sieht es aber anders aus. Also die holen da auch auf und es verbessert sich auch unter unseren Füßen. Also es wird immer besser und wir müssen eigentlich den Benchmark mal wiederholen und unter kontrollierten Bedingungen. Das ist momentan auch schon deutlich mehr drin. Beantwortet das grob die Frage oder gibt es noch weitere Fragen? Dahinten nochmal. Ja, wenn man dieses Elb-Machine, die man da hat, wie robust ist die jetzt dazu, wenn man sozusagen die Internetlogik irgendwie ändert. Also wenn man quasi irgendwo in den, also nicht nur in einer Live, sondern tatsächlich in dem Code von dem, also in der Logik, die damit arbeitet, sozusagen irgendwas ändert, kann man dann das auch irgendwie hinbekommen, dass man die selber der rein nach neu startet oder ist dann mal das Netzwerk kurz weg? Das ist eine super Frage. Das haben wir halt auch gemerkt. Allerdings hat es nie für Probleme gesorgt, glaube ich. Der Punkt ist, du hast ganz recht, wenn man die Logik ändert, so dass zum Beispiel die Antwort auf einen IRC-Befilm, der vorher eine Antwort geliefert hat, sich ändert. Zum Beispiel der ISON-Befilm, den ich vorher erwähnt hatte. Der hat vorher eben Command Not Implemented geliefert. Und wenn ich den Befehl jetzt implementiere, dann liefert der eben die ISON-Liste, die man erwartet. Und die Antwort ist, in den aller allermeisten Fällen ist es gar kein Problem, diese Logik zu ändern. Es wäre, glaube ich, dann ein bisschen tricky, wenn du unter 2 Bedingungen, die eine Bedingung wäre, wenn du ein sehr geschäftiges Netz hast, in dem dauernd Nachrichten rein und raus gehen kannst, vielleicht ein bisschen hinterherhängen. Also wenn ein Klein zum Beispiel jetzt irgendwie 5 Minuten braucht, um eine Nachricht zu lesen, dann kann ich mir vorstellen, dass es vielleicht ein Problem ist, dass ein Klein irgendwie noch die alte Antwort bekommt und ein anderer Klein schon die neue Antwort oder so. Und das ist dann auch der zweite Punkt. Immer dann, wenn du irgendwie State hast, der in dem Klein ist, dann ist das ein Problem. Also mal als konkretes Beispiel angenommen, du sendest einen Join Befehl und du gehst damit in den Channel rein und dann stellen wir fest, der Nutzer hätte eigentlich gar nicht Join dürfen, weil er ist ja eigentlich gebannt, aber Bands haben nicht richtig funktioniert oder so. Und dann würden wir eben den Server fixen, der Server startet wieder hoch, verarbeitet das Protokoll und sieht dann eben, der Join hier resultiert in, der Nutzer ist nicht im Channel. Soweit so gut. Auf Serverseite ist jetzt alles klar. Aber was ist mit dem Klein, der noch läuft, der denkt, er sei in dem Channel. Das ist also zumindest ein UI-Problem gelegentlich. Da kriegen dann Leute, wenn sie in eine Nachricht schicken, oder in eine Meldung, hey, du bist gar nicht in dem Channel, aber der Klein zeigt an, du weißt in dem Channel, dann musst du halt rausgehen und wieder reingehen. Also wir hatten einmal tatsächlich so einen Fall, wo das so war, mit Leuten sind nicht in dem Channel, obwohl sie eigentlich drin waren. Und da haben wir uns dann einfach entschlossen, okay, da gehen wir jetzt als AirCorp rein und kicken einmal alle Leute raus und dann joinen die wieder und dann ist der State quasi gefixt auf den Klein. Für Sowas muss man aufpassen, aber üblicherweise ist es kein Problem. Hier vorne noch eine Frage. Wie viele von den alten Kommunikationen werden gespeichert, oder wie viele von dieser Historie muss gespeichert werden? Das kannst du einstellen. Der Default ist sieben Tage, eben genau aus dem Grund mit dem Session Resume, mit dieser Session Resume Idee, dass man eben bis zu sieben Tage seinen Computer einfach ausmachen können soll und dann wieder weitermachen kann. Wenn du jetzt aber sagen möchtest, ich möchte weniger Daten vorhalten, was natürlich löblich ist, dann kannst du auch sagen, okay, ich stelle das jetzt auf eine Stunde. Der Punkt ist, ab dann, wenn du quasi einen Netzausfall hast, der so lange anhält, wie deine Datenspeichhaft ist, also wenn der darüber hinausgeht, dann hast du natürlich gegebenenfalls ein Problem. Wenn also du Nachrichten hast, die sich Kleins noch nicht abgeholt haben, weil sie eine sehr langsame Netzverbindung haben, dann werden die sozusagen vorher gelöscht, bevor sie ausgeliefert werden können und wenn du jetzt also die Vorhaltezeit auf eine Minute stellst und es gibt Leute, die eine Minute Netzausfall haben, ist das vielleicht blöd. Was hat die Technik vorgibt? Weitere Fragen? Ich glaube, damit sind wir auch schon über Zeit. Dann würde ich sagen, wenn ihr noch andere Fragen habt, die euch einfallen sollten, ich bin noch den ganzen Tag hier und morgen auch noch, abstrakt mich einfach spontan und ansonsten vielen Dank für eure Aufmerksamkeit.