GrieferGames-Tutorial: Serverprobleme beim Verbinden (io.netty.channel / connection timed out / sending too many packets)

Heyho,

aufgrund häufiger Nachfragen mit Verweis auf verschiedene Versionen älterer Beiträge von mir, habe ich entschlossen, ein Tutorial zum Thema Verbindungsfehler zu erstellen. Dadurch kann das Thema dauerhaft aktuell gehalten und an entsprechende Änderungen angepast werden, ohne in einer Vielzahl an Themen nach einem aktuellen Stand suchen zu müsssen.

Vorwort: Datenverkehr - Warum passiert das?

Eine Anfrage im Internet zwischen deinem Endgerät und einem Server wird in einzelne Datenpakete zerlegt. Diese Pakete enthalten Informationen zu ihrem Ursprung, ihrem Ziel, ihrer Art von Verarbeitung, sowie die reinen Daten-Informationen, welche eigentlich gesendet werden. Da pro Paket immer nur eine gewisse Größe möglich ist werden umfangreichere Anfragen in eine Vielzahl an Paketen zerlegt und am Ziel wieder zusammengesetzt.

Gehen hierbei Datenpakete verloren oder werden unterwegs im Netz "beschädigt" (fehlerhaft gelesen, geschrieben, übertragen), muss dieses vom Ziel entweder auf Grundlage von anderen Datenpaketen repariert werden (FEC-Fehler) oder komplett neu vom Ursprung angefordert werden (CRC-/CV-Fehler).

Beachte hierbei, dass eine schnelle Internetverbindung nicht gleichzeitig eine stabile Internetverbindung bedeutet.

• Eine hohe Bandbreite heißt nur, dass viele Datenpakete in kurzer Zeit transportiert werden.
• Die Latenz sagt nur aus, wie lange das Datenpaket für die Übermittlung zum Server benötigt hat.
  • Eine zu hohe Latenz führt potentiell häufiger zu timeout-Fehlern oder ist Ursache für einen packet-Spam.
• Die Qualität wird dadurch bestimmt, wie viele der gesendeten Datenpakete unbeschädigt ankommen bzw. FEC-seitig reparierbar sind.
  • Zu viele FEC oder CRC-Fehler führen zu einer beeinträchtigten Verbindung

Was ist ein "io.netty.channel"-Fehler?

io = I/O = Input-Output, typischer Informationsfluss in der Computertechnik (Eingabe-Ausgabe-Verfahren, Anfrage-Antwort, Server-Client, etc.)

netty = API-Name (Mehr Informationen)

netty.channel = Kernkanal-API zur asynchronen und ereignisgesteuerten Abstraktion verschiedener Transporte

"io.netty.channel"-Fehler treten in Minecraft auf, wenn die verwendete Kern-API für das Verbinden der Client-Anfrage in RIchtung Server scheitert. Im Normalfall passiert das, weil der Client keine bzw. unzureichende oder fehlerhafte Daten liefert.

Dies kann verschiedene Ursachen haben, welche in diesem Tutorial behandelt werden. Die Ursachen sind dabei nicht für jeden Fehler exklusiv, sondern können zu jedem dieser Fehler beitragen oder andere Fehlerquellen "verschlimmern".

Was ist ein Timeout?

Bei einem Timeout sendet dein Client eine Anfrage an den Server. Dein Endgerät erwartet, dass der Server diese Anfrage innerhalb einer gewissen Zeit beantwortet. Bleibt die Antwort über einen gewissen Zeitraum hinweg aus, trennt das System die Verbindung mit der Meldung "timed out", zu deutsch "Zeitüberschreitung". Die erwartete Zeit für eine Antwort ist überschritten. Die Verbindung wird getrennt, da keine Antwort erfolgt ist und das System davon ausgeht, dass das Ziel nicht antwortet.

Dieser Vorgang kann selbstverständlich auch umgekehrt erfolgen. Sendet der Server eine Anfrage an deinen Client und diese wird nicht beantwortet, trennt der Server die Verbindung, da er davon ausgeht, dass dein Client nicht mehr verbunden ist. Üblicherweise erfolgt dies mit einer Fehlermeldung, welche aussagt, dass der Remotehost die Verbindung getrennt hat.

Was ist ein Packet-Spam?

Wenn der Server eine unnormale Vielzahl von Datenpaketen von deinem Client auf einmal erhält, interpretiert der Server dies als Versuch ihn zu "überfordern" oder gar als "Angriff" und trennt die Verbindung zu dir, um sich zu schützen. Du erhältst eine Fehlermeldung mit dem Inhalt "packet spam" oder "sending too many packets", zu Deutsch "sendet zu viele Pakete".

Ein Packet-Spam ist daher so ziemlich das Gegenteil vom "timeout"-Fehler, hat aber in der Regel die gleiche grundlegende Ursache: Das von deinem Client gesendete Signal benötigt "zu lange" um beim Server anzukommen. In den meisten Fällen liegt irgendwo ein "Flaschenhals", welcher das Signal ausbremst und die Datenpakete zwischen deinem Client und dem Server aufhält. Sobald die Datenpakete die "Blockade" überwunden haben oder diese sich auflöst, werden diese alle auf einmal gesendet.

Was kann ich nun tun? Mögliche Fehlerbehebung

Generelle io.netty.channel-Probleme:

• Java veraltet
  • Der Minecraft-Launcher kommt standardmäßig mit einer eigenen Java-Instanz, welche mit Client-Updates auch aktualisiert wird. Manchmal ist diese dennoch veraltet oder fehlerhaft. Hier hilft es dann im Launcher unter Installationen > Bearbeiten > Mehr Optionen eine aktuelle Java-Instanz vom eigenen PC zu nutzen.
  • Java kann in der Systemsteuerung deines Betriebssystems aktualisiert werden. Falls du Java noch nicht seperat installiert hast, kannst du dir einen Installer von der offiziellen Webseite herunterladen.

• Benutzt du die passende Minecraft-Version für den Server?
  • Für das optimale Spielen auf GrieferGames.net "Citybuild 1.8" wird Minecraft 1.8.9 empfohlen!
  • Für das optimale Spielern auf GrieferGames.net "Citybuild Cloud" wird die aktuelle Minecraft-Version empfohlen!
• Benutzt du die aktuelle Minecraft-Version für Bedrock?
  • Du kannst den Softwarestand über den entsprechenden Store des Endgerätes prüfen.
  • Die Beta-Versionen der App werden nicht unterstützt!

Timeout- & Packet-Spam-Probleme:

• Verbindest du dich auf GrieferGames über griefergames.net?
  • Viele unserer Alternativadressen wurden inzwischen deaktiviert.
  • Für das Verbinden auf unsere Server empfehlen wir die Adresse "griefergames.net".
    • Alternativen für die Java-Edition sind:
      • alt.griefergames.net
      • bungee1.griefergames.net
      • bungee2.griefergames.net
      • griefergames.de
    • Die Alternativadresse cloud.griefergames.net kann direkt auf "Citybuild Cloud" verbinden. Du benötigst hierfür mindestens den Premium-Rang.
    • Für die Bedrock-Edition bestehen keine Alternativ-Adressen. (siehe hierzu Firewall-/Port-Einstellungen)
      
• Spielst du über einen VPN/Proxy/festen DNS-Server, welcher deine Daten "umleitet"?
  • Versuch einen direkten Verbindungsaufbau ohne "Zwischenstopp", um einen Fehler bei diesem auszuschließen.
  • Derlei Dienste gibt es auch für mobile Endgeräte. Manchmal sind diese sogar bordseitig aktiv.
• Benutzt du Sicherheitssoftware (Antivirus/Malware/Sicherheitspakete)?
  • Die entsprechenden Programme durchsuchen den Datenverkehr der Netzwerkverbindung, um potentielle Bedrohungen aufzuspüren. Der Datenverkehr wird dafür kurzzeitig angehalten und in der Software geprüft, was zu einer Verzögerung führen kann.
• Bitte überprüfe, dass deine Firewall nicht den Minecraft-Port '25565' und den Bedrock-Port '19132' über TCP und UDP blockiert hat.
  • Wie du das am Besten machst, erfährst du durch eine Recherche auf Google oder in Rücksprache mit dem Hersteller-Support des Gerätes bzw. der Software.
  • Die Alternativports der Java-Edition sind 25566 und 25567.
    Für eine optimale Freigabe ist daher der Bereich 25565 - 25567 auf TCP und UPD freigegeben.
  • Der Alternativport der Bedrock-Edition ist 19134.
    Für eine optimale Freigabe ist daher der Bereich 19132 , 19134 auf TCP und UDP freigegeben.
• Wenn du die Bedrock-Edition verwendest kann das Deaktivieren der MysteryMod-Möbel den Datenverkehr reduzieren und damit die Qualität verbessern (weniger Datenbelastung). Die entsprechende Anfrage erhälst du, wenn du dich mit dem Server über den Standard-Port 19132 verbindest.
  • Der Alternativport 19134 hat die Zusatzressourcen (MysteryMod-Möbel) standardmäßig deaktiviert und kann bei Problemen ebenfalls genutzt werden.

Ein weiterer Faktor neben diesen typischen "Flaschenhälsen" sind natürlich auch die eigene Internetverbindung und die Latenz zwischen Server und Client.

• Für eine stabile Internetverbindung ist eine Bandbreite von mehr als 6 MBit/s im Downstream und 2 MBit/s im Upstream erforderlich. Ich empfehle eine Bandbreite von mindestens 16 MBit/s im Downstream und 6 MBit/s im Upstream.
  • Die genaue Bandbreite des Anschluss lässt sich über das Menü eures Routers ermitteln. In der Statusübersicht werden die Werte normalerweise angegeben.
  • Alternativ könnt ihr jederzeit eine Prüfung des Anschluss durch euren Anbieter veranlassen.
• Die Latenz beschreibt die Dauer die das Signal zwischen Client und Server und zurück benötigt. Sie wird auch als "ping" bezeichnet.
  • Werte von 10-25 ms sind optimal für einen Verbindungsaufbau.
  • Pingzeiten bis zu 50 MBit/s sind verträglich, alles darüber wird unangenehm.
  • Die Latenz sollte in keinem Fall über 100ms liegen.
• "LAN-Ersatzlösungen", wie WLAN-Verbindungen, Powerline-Verbindungen oder USB-Tethering verzögern den Verbindungsaufbau und den Paketdurchsatz. Solche Verbindungsarten im Heimnetz können ebenfalls zum "Stau" der Datenpakete führen.
  • Teste die Verbindung zeitweise mit einer mobilen Datenverbindung.
  • Entferne andere Geräte vom Router oder deaktiviere deren WLAN-Verbindung für die Dauer deines Tests, um Einflüsse aus deinem Heimnetzwerk zu verhindern.
• Dienste wie IPTV oder VoIP haben bei fast allen Anbietern eine "QoS"-Priorisierung.
  • Telefoniert also jemand in eurem Heimnetzwerk oder schaut über das Internet Fernsehen, so ist dieser Datenverkehr bevorzugt und eurer wird "hintenangestellt".
• Mobile Daten werden über die Mobilfunk-Anbieter nach einem "shared medium"-Prinzip ausgegeben.
  • Die Verbindungsqualität schwankt daher abhängig der aktuell an der Funkzelle verbundenen Nutzer und deren Nutzungsverhalten.
  • Teste ggf. die Verbindung über das WLAN des Routers.

Eine letzte Möglichkeit ist natürlich auch serverseitig zu finden und das sind "Lag-Spikes" des Servers.

Ist der Server gerade durch zu viele Anfragen ausgelastet (wie bei DDoS-Angriffen/Hoster-Problemen), dauert es ebenfalls einen kurzen Moment bis deine Datenpakete verarbeitet werden. Wenn diese sich in der Zeit "anstauen" kann dies ebenfalls als "Paket-Spam" interpretiert und du vom Server geworfen werden.

Aktuelle Informationen zur Serverperformance findest du auf unserem Discord und im Serverperformance-Thread.

Die Kombination aus zwei oder mehr dieser Punkte sorgt natürlich für ein höheres Fehlerpotential. Es kann also sein, dass alle einzelnen Bedingungen in Ordnung sind und eine ping-Zeit von 45 ms in Kombination mit einer Nutzung der mobilen Daten und aktuellen Hoster-Problemen dennoch zum Fehler führt.

Dieses Tutorial ist Teil einer Tutorial-Reihe!

Feedback / Verbesserungsvorschläge zu diesem Tutorial bitte als Antwort darunter posten.