Ein Texturenpaket fürs ganze Netz — und warum es zweimal kam
Das Paket lud, scheiterte, und danach war gar keins mehr da. Die Ursache lag nicht am Paket, sondern daran, dass zwei Stellen dasselbe verschickt haben.
Blackzack988 Wörter · 5 Min. Lesezeit
- minecraft
- bedrock
- fehlersuche
Ein Texturenpaket kann ein Minecraft-Server seinen Spielern beim Betreten schicken. Bei mir soll es netzwerkweit gelten — dieselbe Optik auf allen Servern, damit ein Wechsel nicht aussieht wie ein anderes Spiel.
Das Fehlerbild: Das Paket lädt, bricht ab, und danach hat der Spieler gar kein Paket mehr.
Was ich zuerst ausgeschlossen habe
Bevor man in einem verteilten System sucht, schließt man das Einfache aus. In diesem Fall:
- Ist die Adresse erreichbar? Ja, Statuscode 200.
- Stimmt die Prüfsumme? Ja, die Datei am Zielort hat genau die Prüfsumme, die in der Konfiguration steht.
- Ist das Archiv gültig? Ja, lässt sich fehlerfrei entpacken.
Damit war die halbe Fehlersuche erledigt — und zwar mit zwei Befehlen. Ich mache das inzwischen immer zuerst, weil ein defektes Paket und ein Zustellungsproblem völlig verschiedene Suchrichtungen sind.
Die erste Ursache: zwei Absender
Das Paket wurde zweimal geschickt. Einmal über die Serverkonfiguration, wie ich es eingerichtet hatte. Und einmal von einem Plugin, das eine eigene Paketauslieferung mitbringt — konfiguriert mit derselben Adresse und derselben Prüfsumme.
Für den Client sind das zwei Sendungen desselben Pakets mit verschiedenen Kennungen. Eine davon scheitert, und daraufhin verwirft er alles.
Das Tückische daran: Beide Absender waren für sich korrekt konfiguriert. Es gab keine falsche Adresse, keine falsche Prüfsumme, keinen Fehler in einer Datei. Der Fehler entsteht erst aus der Kombination.
Behoben durch Abschalten der Auslieferung im Plugin — was sich sogar ohne Neustart übernehmen ließ, obwohl das Plugin gar keinen eigenen Nachladebefehl in seiner Beschreibung führt. Ein Fall, in dem Ausprobieren schneller war als Suchen.
Die zweite Ursache: fehlende gemeinsame Kennung
Nach der ersten Behebung lud das Paket. Und wurde bei jedem Serverwechsel neu geladen.
Der Grund: Ein Paket hat eine Kennung, die der Server mitschickt. Fehlt sie in der Konfiguration, erfindet der Server eine — sichtbar als beiläufige Zeile im Protokoll, dass keine Kennung gesetzt sei und ein Standardwert verwendet werde.
Für den Client sind zwei Kennungen zwei verschiedene Pakete, auch wenn es dieselbe Datei mit derselben Prüfsumme ist. Bei jedem Wechsel wurde also mehrere Megabyte neu übertragen.
Behoben, indem alle Server dieselbe Kennung tragen. Danach wird das Paket einmal geladen und über den ganzen Aufenthalt behalten.
Infobox
Die Zeile im Protokoll stand da, seit ich das eingerichtet habe. Sie ist keine Warnung, sondern eine Information, und sie geht zwischen hunderten Startzeilen unter. Beim Suchen nach „Paket wird neu geladen" hätte man sie nie gefunden — sie erscheint beim Start, das Symptom beim Wechsel. Das ist ein wiederkehrendes Muster: Die Ursache steht im Protokoll eines anderen Zeitpunkts als das Symptom.
Zwei Pakete, nicht eins
Ein Punkt, der bei Crossplay immer wieder für Verwirrung sorgt und den ich hier festhalte: Es gibt zwei getrennte Pakete.
Das eine gilt für Java-Clients und wird vom Server über eine Adresse ausgeliefert. Das andere gilt für Bedrock-Clients, liegt bei der Übersetzungsschicht und wird von dort verteilt.
Wer eines davon ändert, ändert die Optik für die Hälfte der Spieler. Und wer eine Datei am falschen Ort bearbeitet, ändert gar nichts: Bei mir lagen in einem Serververzeichnis Kopien der Bedrock-Pakete, die niemals ausgeliefert wurden — ausgeliefert wird aus dem Verzeichnis der Übersetzungsschicht auf dem Proxy. Wer nur die Kopie ändert, sucht anschließend den Fehler an der falschen Stelle.
Wie ich Pakete heute ausliefere
Aus diesem Fehler ist ein festes Verfahren geworden, das mehrere Server und beide Spielfassungen abdeckt.
Eine Adresse für alle. Das Paket liegt an genau einer Stelle und wird von dort ausgeliefert. Keine Kopien in Serververzeichnissen.
Eine Prüfsumme, überall dieselbe. Sie steht in der Konfiguration jedes Servers und wird nach jeder Änderung am Paket neu erzeugt.
Eine gemeinsame Kennung. Damit erkennt der Client bei einem Serverwechsel, dass es dasselbe Paket ist.
Die Fassung im Dateinamen. Beim Ändern entsteht eine neue Datei, statt die alte zu überschreiben. Damit kann kein Zwischenspeicher irgendwo eine alte Fassung unter der aktuellen Adresse halten.
Genau ein Absender. Alles, was das Paket sonst noch verschicken könnte, ist abgeschaltet.
Der letzte Punkt ist der, der mich diesen Fehler gekostet hat — und er ist in gewachsenen Aufbauten der wahrscheinlichste. Serverpakete bringen ihre eigenen Mechanismen mit, und die sind selten offensichtlich dokumentiert.
Die Prüfung, die ich vor jeder Auslieferung mache
curl -sI https://.../paket.zip | head -3 # erreichbar?
curl -s https://.../paket.zip | sha1sum # Prüfsumme
unzip -t paket.zip | tail -1 # gültiges Archiv?Drei Befehle, zwanzig Sekunden, und sie schließen die halbe Fehlersuche aus. Wenn alle drei in Ordnung sind, liegt das Problem in der Zustellung — nicht am Paket.
Diese Aufteilung in „ist die Datei in Ordnung" und „kommt sie richtig an" hat mir seitdem bei jedem Paketproblem als Erstes geholfen. Sie halbiert den Suchraum mit dem geringstmöglichen Aufwand, und sie funktioniert unabhängig davon, wie kompliziert der Aufbau dahinter ist.
Was ein Paket enthalten darf, ohne Ärger zu machen
Ein netzwerkweites Paket wird jedem Spieler beim Betreten geschickt. Das setzt der Größe Grenzen und stellt Fragen, die man vorher klären sollte.
Die Größe entscheidet über den Einstieg. Ein Paket von wenigen Megabyte lädt in Sekunden. Eines von hundert Megabyte ist eine Wartezeit vor dem ersten Spielerlebnis — und der häufigste Grund, warum jemand abbricht.
Nicht erzwingen. Ein fehlgeschlagener Ladevorgang darf niemanden aussperren. Bei mir ist das Paket ausdrücklich optional; wer es nicht bekommt, sieht Standardoptik und kann trotzdem spielen.
Die Rechte an den Inhalten klären. Texturen aus gekauften Paketen weiterzuverteilen ist nicht automatisch erlaubt, auch nicht an die eigenen Spieler. Das steht in den Bedingungen des jeweiligen Pakets.
Der letzte Punkt wird gerne übersehen, weil das Verteilen technisch trivial ist. Technisch möglich und erlaubt sind zwei verschiedene Fragen.
Der Merksatz, der geblieben ist
Bei Paketproblemen in dieser Reihenfolge prüfen:
- Adresse, Prüfsumme, Archiv. Zwei Befehle, schließt die Hälfte aus.
- Schickt noch jemand anderes dasselbe Paket? In modernen Aufbauten kann ein Paket von mehreren Stellen kommen.
- Haben alle Server dieselbe Kennung?
- Bearbeite ich die Datei, die tatsächlich ausgeliefert wird?
Punkt 2 und 4 sind die, die mich Zeit gekostet haben — und beide haben dieselbe Wurzel: In einem gewachsenen System gibt es mehr Wege für dieselbe Sache, als man im Kopf hat.