CrossLink entsteht: ein eigenes Plugin für zwei Server

Mit dem Wechsel auf Java kam ein zweiter Server dazu: einer zum Spielen, einer zum Ausprobieren. Und damit die Frage, wie man dazwischen wechselt.

Die übliche Antwort ist ein Proxy — eine Zwischenschicht, über die alle Verbindungen laufen und die Spieler zwischen Servern verschiebt, ohne dass sie sich neu verbinden. Ich habe mich zunächst dagegen entschieden und stattdessen ein eigenes Plugin gebaut.

Warum kein Proxy

Weil ein Proxy eine zusätzliche Schicht ist, die alles betrifft. Er wird zum Eingang für sämtliche Verbindungen. Fällt er aus, ist alles weg. Er muss die Protokollversionen unterstützen, er braucht eigene Konfiguration für die Weiterleitung, und die Hintergrundserver müssen so eingestellt sein, dass sie nur ihm vertrauen.

Weil es einen einfacheren Weg gibt. Seit einiger Zeit kennt Minecraft eine Weiterleitung, bei der der Server dem Client sagt: verbinde dich bitte dorthin. Der Client baut die Verbindung selbst neu auf.

Damit ist der Wechsel ein Befehl im Plugin und keine Infrastruktur. Inventar und Position bleiben pro Server getrennt — das war für meinen Fall in Ordnung, weil der zweite Server ausdrücklich ein anderer Ort ist.

Was die erste Fassung kann

Wechselbefehle, je einer pro Ziel, mit den Adressen aus der Konfiguration.

Eine Statistikansicht für die eigenen Werte: Spielzeit, abgebaute Blöcke, zurückgelegte Strecke, Tode, Mob-Kills.

Eine Bestenliste, die beide Server umfasst — als Truhenoberfläche mit umschaltbaren Kategorien.

Eine Kopf- und Fußzeile in der Spielerliste, die zeigt, wer auf dem jeweils anderen Server ist.

Die Entscheidungen, die den Aufbau tragen

Ein Zwischenspeicher statt Abfragen auf Zuruf. Der naheliegende Weg für eine Bestenliste über alle Spieler ist, die Statistiken abgemeldeter Spieler zu lesen. Das ist eine Falle: Diese Abfrage lädt die Statistikdatei bei jedem Aufruf neu von der Platte. Für Summen über mehrere tausend Materialien und dutzende Spieler wäre das ein sekundenlanger Stillstand des Servers.

Also schreibt jeder Server die Werte seiner anwesenden Spieler regelmäßig und beim Abmelden in eine eigene Datei und beantwortet Anfragen daraus. Fremdwerte sind damit bis zu einer halben Minute alt — für eine Bestenliste völlig ausreichend.

Der Austausch läuft über kurzlebige Verbindungen im internen Netz, eine Zeile hin, eine zurück, mit einem gemeinsamen Geheimnis. Kein dauerhafter Kanal, der abreißen kann.

Als Adresse dient der Containername, nicht die Adresse. Container-Adressen ändern sich bei einem Neustart. Der Name bleibt.

Die Austausch-Threads fassen die Spiel-Schnittstelle nicht an. Sie lesen nur Felder, die der Haupttakt befüllt. Alles andere wäre eine Einladung für schwer auffindbare Fehler, weil die Minecraft-Schnittstelle nicht für parallelen Zugriff gebaut ist.

Was die Spielerliste nicht kann

Ein Punkt, an dem ich einen halben Tag verloren habe: Ich wollte die Spieler des anderen Servers als echte Einträge in der Spielerliste anzeigen.

Das geht nicht — jedenfalls nicht über die unterstützte Schnittstelle. Die Paper-Schnittstelle bietet keinen Weg, fremde Spieler dort einzutragen. Es ginge nur über selbst gebaute Pakete, und das ist genau die Sorte Lösung, die bei jedem Minecraft-Update bricht.

Also Kopf- und Fußzeile: Dort steht, wer drüben ist. Weniger elegant, dafür stabil. Ich habe mir angewöhnt, bei solchen Entscheidungen die Frage zu stellen, wie sie das nächste Update überlebt.

Warum ich später doch einen Proxy genommen habe

Der Eintrag beschreibt den Stand von August. Ein paar Wochen später lief das Netzwerk trotzdem über einen Proxy — und der Grund war keiner der Punkte, die ich damals abgewogen hatte.

Der Auslöser war die Bedrock-Seite. Ohne Proxy braucht jeder Server seine eigene Übersetzungsschicht, mit eigenem Port und eigenem Paket. Bei zwei Servern ist das lästig, bei vier unhaltbar — jedes Texturenpaket, jede Zuordnung, jede Aktualisierung müsste mehrfach gepflegt werden.

Der zweite Grund war der Eingang. Ohne Proxy muss jeder Server öffentlich erreichbar sein. Mit Proxy gibt es einen Eingang, und die Server dahinter sind dicht.

Was ich damals richtig eingeschätzt hatte: Ein Proxy ist eine zusätzliche Schicht, die alles betrifft, und sein Ausfall ist der Ausfall von allem.

Was ich unterschätzt hatte: Wie schnell die Zahl der Server wächst, und wie viel Aufwand pro Server anfällt, wenn es keine gemeinsame Schicht gibt. Bei zwei Servern war meine Rechnung richtig. Bei vier war sie es nicht mehr.

Was aus dem Plugin geworden ist

Die Wechselbefehle sind geblieben — sie laufen jetzt über den Proxy statt über die direkte Weiterleitung, aber die Bedienung ist dieselbe.

Was dazugekommen ist, hat nichts mit dem Wechsel zu tun und ist inzwischen der wertvollere Teil: die serverübergreifenden Statistiken, die Bestenliste über alle Server, das Hilfe-Menü, die Profilansicht.

Das ist ein Muster, das ich bei eigenen Plugins öfter sehe: Der Grund für den Bau ist selten der Grund, warum es später wertvoll ist. Ich habe es für den Serverwechsel gebaut. Benutzt wird vor allem alles andere.

Und daraus folgt ein praktischer Rat: Wenn man ein eigenes Plugin baut, lohnt es sich, den Rahmen etwas größer zu ziehen als den Anlass — nicht mit Funktionen, sondern mit Struktur. Ein Plugin, das nur eine Sache kann, muss man beim zweiten Bedarf neu schneiden.

Wie es weitergeht

Die erste Fassung ist an einem Tag entstanden und deckt ab, was ich brauchte. Was ich schon absehen kann:

• Rechte für den Wechsel. Im Moment darf jeder überall hin. Sobald ein Server nicht öffentlich sein soll, braucht es eine Prüfung.
• Bedrock. Die Weiterleitung funktioniert für Java-Clients. Für Bedrock-Spieler läuft sie über die Übersetzungsschicht, und die braucht eine eigene Behandlung. Das wird der nächste Eintrag.
• Ein Hilfe-Menü. Wenn es mehr als drei Befehle gibt, findet sie niemand mehr.