Monster Hunter: World Proxy: Wer hostet die Session?

Die Online-Seite von Monster Hunter: World arbeitet nicht nach der Logik eines zentralen Servers, der eine persistente Welt beherbergt. Die Spieler versammeln sich in einer Session, zwischen den Teilnehmern einer Quest wird eine Verbindung aufgebaut, und der Rechner eines Spielers führt die Session aus. Da es keinen einzelnen Endpoint zum Verbinden gibt, existiert auch keine Option, „den Proxy auf den Server zu richten“.

Das verändert die Proxy-Frage. Die Frage lautet nicht mehr „über welchen Weg erreiche ich welchen Server“, sondern „welchen Stream berührt die Regel, die ich geschrieben habe“. Login, Versionsprüfung und Matchmaking-Aufrufe verhalten sich völlig anders als der Echtzeit-Stream während der Jagd.

Nachfolgend finden Sie zuerst die Architektur, dann die drei verschiedenen Bedeutungen des Regionsbegriffs, anschließend die netzseitige Mechanik des Verbindungsaufbaus und schließlich die Frage, wie sich die Einrichtung messen lässt.

Zwischen wem wird die Verbindung aufgebaut, wenn Sie auf die Jagd gehen?

Der Ablauf verteilt sich auf vier Akteure. Der Store-Client prüft Version und Session; der Spiel-Client führt die Matchmaking-Aufrufe aus; der Proxy-Ausgang trägt diese Aufrufe, sofern Sie ihn eingetragen haben; und sobald die Jagd beginnt, ist die Gegenstelle kein Dienst mehr, sondern der Rechner eines anderen Spielers, der die Session hostet.

Dieser letzte Schritt ist der entscheidende. Die Adresse der Gegenstelle ist nicht fest, sie ändert sich mit jeder Session und lässt sich in keine Konfigurationsdatei schreiben. „Den Weg zum Spielserver in einen Tunnel legen“ ist daher ein Wunsch ohne technische Entsprechung.

Aus demselben Grund verläuft auch die Diagnose von Verbindungsproblemen anders. Ist ein Dienst nicht erreichbar, ist das Problem für alle gleich; kommt keine Verbindung zum Session-Host zustande, liegt das Problem auf dem Weg zwischen zwei Endpunkten, und die Netzwerkkonfiguration beider Seiten muss gemeinsam betrachtet werden.

In der Praxis hilft diese Unterscheidung so: Tritt derselbe Fehler bei allen auf, ist es Zeitverschwendung, Ihre Konfiguration zu ändern – dann muss man die Dienstseite abwarten. Tritt der Fehler nur bei bestimmten Spielern auf, ist die Variable Ihr Netz oder das der Gegenstelle. Die erste Frage muss immer lauten: „Bei wie vielen Personen tritt dieses Problem auf?“ Die Antwort sagt Ihnen unmittelbar, welche Schicht Sie sich ansehen müssen.

Behalten Sie auch den Store-Client in der Gleichung. Eine Versionsabweichung trennt Spieler voneinander, sieht aber aus wie ein Netzwerkfehler: Sind beide Seiten auf unterschiedlichen Patches, kommt gar keine Verbindung zustande, und das Symptom wird mit einem Router-Problem verwechselt. Vor dem Herumschrauben an Regeln ist die Prüfung, ob beide Seiten dieselbe Version haben, die billigste Kontrolle.

Gibt es in diesem Spiel einen mietbaren Server?

Die kurze Antwort lautet nein. Anders als bei vielen Sandbox-Titeln wird hier keine Server-Software verteilt, die die Community aufsetzen und betreiben könnte. Sie können keinen Endpoint auf Ihrem eigenen Rechner betreiben und Freunde dorthin einladen und sich auch nicht über eine feste Adresse treffen.

Ein Vergleich kann hilfreich sein: Bei Titeln, die eigene Server erlauben, ist eine Proxy- oder Routing-Entscheidung weit sinnvoller, weil es ein festes Ziel gibt, auf das geroutet werden kann. Wie dieser Unterschied in der Praxis aussieht, auf der Seite eines Titels mit eigenem Server-Hosting .

Das Fazit: Der Proxy ändert hier nicht das Ziel, sondern leitet lediglich den ausgehenden Verkehr Ihres Clients über eine bestimmte Leitung. In Campus- oder Firmennetzen, in denen ausgehender Verkehr eingeschränkt ist, kann das sinnvoll sein; genutzt wird es, um Zugang zu ermöglichen, nicht um die Session-Performance zu verbessern.

Diese Architektur hat eine weitere Folge: Die Qualität der Session hängt von der Leitung des hostenden Spielers ab. Nicht alle in einer Gruppe erleben dasselbe; wer dem Host geografisch näher ist, sieht weniger Latenz. Hat eine einzelne Person in der Gruppe eine schwache Verbindung, lässt sich das nicht durch die Wahl eines Ausgangs ausgleichen – es hilft nur, wenn die Person mit der besseren Leitung die Session eröffnet.

• Lassen Sie die Session bevorzugt von dem Spieler mit der stabilsten Leitung eröffnen.
• Berücksichtigen Sie, dass die Last des Hosts mit wachsender Gruppengröße steigt.
• Da es keinen festen Endpoint gibt, denken Sie Port-Weiterleitungen auf Host-Seite.

Region ist dreierlei: Präferenz, Konto und Netzwerkstandort

Das Erste ist die Matchmaking-Präferenz: Das Spiel berücksichtigt Ihre Sprach- und Regionseinstellungen, wenn es entscheidet, mit wem es Sie zusammenführt. Das Zweite ist die Kontoregion: Das Land Ihres Store-Kontos bestimmt Preisgestaltung und Store-Inhalte und ändert sich nicht mit Ihrem Netzwerkstandort. Das Dritte ist Ihr Netzwerkstandort, also die geografische Entsprechung der IP-Adresse, über die Sie nach außen gehen.

Diese drei sind nicht austauschbar. Ein Proxy ändert nur das Dritte. Versuche, die Kontoregion zu ändern, verstoßen gegen die Nutzungsbedingungen der Plattform und sind nicht Thema dieser Seite. Zu prüfen, wie die Store-Seite aus einem anderen Land aussieht, ist dagegen eine legitime Rechercheaufgabe; die Methode regionale Recherche in Game-Stores wird im Beitrag erklaert.

Praktische Konsequenz: Ihr Ausgangsland in eine entfernte Region zu verlegen, führt Sie nicht mit den Spielern dieser Region zusammen und überschreibt nicht die Präferenz, die das Spiel Ihnen zuweist. Das Einzige, was passiert, ist, dass Ihre über TCP laufenden Aufrufe einen längeren Weg nehmen.

Die Verwirrung geht meist von der Spracheinstellung aus. Oberflächensprache, Store-Sprache und Matchmaking-Präferenz stammen aus drei verschiedenen Quellen; eine davon zu ändern, beeinflusst die anderen nicht. Wenn sich beim Wechsel des Ausgangslandes die Sprache mancher Seiten ändert, bedeutet das nicht, dass das Spiel Sie in eine andere Region verschoben hat; es zeigt nur, woher diese Seite die Anfrage erhalten hat.

NAT-Mapping und wie sich zwei Endpunkte finden

Sind beide Spieler hinter einem Router, kommt die Verbindung zustande, indem beide Seiten Pakete nach außen senden und so ein temporäres Mapping öffnen. Die Matchmaking-Schicht übermittelt diese Informationen wechselseitig, und beide Endpunkte versuchen, einander direkt zu erreichen. Wie vorhersehbar das Mapping ist, entscheidet darüber, ob die Verbindung zustande kommt.

Sobald sich ein Vermittler dazwischenschaltet, bricht diese Mechanik. Ein HTTP-Proxy trägt ohnehin nur TCP; auf SOCKS5-Seite ist UDP Associate eine theoretische Möglichkeit, aber sowohl Server als auch Client müssen sie unterstützen. Wie der Mechanismus arbeitet, SOCKS5-UDP-Unterstuetzung im Beitrag; den begrifflichen Unterschied zwischen Vermittler und Adressumsetzung finden Sie im Vergleich von Proxy und NAT naeher ausgefuehrt.

Kommt keine Verbindung zustande, ist die Reihenfolge der Lösungsschritte daher folgende: Wechseln Sie zuerst auf eine Kabelverbindung, prüfen Sie dann die Router-Konfiguration und ob ein doppelter Router vorliegt, und klären Sie anschließend, ob Ihr Anbieter Ihnen eine geteilte Adresse zuweist. Der Proxy ist auf dieser Liste keine Lösung, sondern meist eine zusätzliche Variable.

Das Thema geteilte Adresse ist besonders wichtig. Wenn Ihr Anbieter Ihnen keine eigene öffentliche Adresse gibt, ist nicht zu erwarten, dass eingehende Verbindungsanfragen Sie erreichen; in diesem Fall funktioniert das Beitreten reibungsloser als das Hosten einer Session. Dieselbe Grenze gilt für jede Art von Ausgang, dessen Adresse viele Nutzer teilen, und sie lässt sich nicht mit einer Konfigurationseinstellung überwinden.

Hinzu kommt die Falle der doppelten Schicht. Wenn gleichzeitig ein Tunnel auf Geräteebene und eine separate Definition in der Anwendung laufen, wird unklar, welche Schicht den Verkehr trägt, und eine Diagnose wird unmöglich. Vereinfachen Sie die Einrichtung: Halten Sie immer nur eine Routing-Schicht gleichzeitig aktiv.

Streams, die der Tunnel trägt – und die er nicht trägt

Den Geltungsbereich in zwei Spalten aufzuteilen, ergibt ein klareres Bild als lange Erklärungen. Links stehen die Streams, die Ihre Proxy-Regel tatsächlich erfassen kann, rechts jene, die außen vor bleiben, egal wie weit die Regel gefasst ist.

Der Unterschied entsteht aus dem Protokoll. Alles, was über TCP läuft und in einen von einem Vermittler geöffneten Tunnel passt, steht in der linken Spalte: Login, Versionsprüfung, Store-Vorgänge, Matchmaking-Aufrufe und Downloads. Alles, was in Echtzeit läuft, latenzempfindlich ist und über UDP transportiert wird, steht in der rechten Spalte. Details zur Protokollwahl finden Sie SOCKS5 Proxy Seite ansehen.

Diese Tabelle von vornherein zu akzeptieren, verkürzt die Diagnosezeit. Der Satz „Ich habe die Regel richtig geschrieben, aber das Spiel geht immer noch über meine normale Leitung“ beschreibt fast immer keinen Fehler, sondern das erwartete Verhalten der rechten Spalte.

Der praktische Weg, den Geltungsbereich zu überprüfen, besteht darin, beide Seiten getrennt zu testen. Öffnen Sie zuerst den Store-Client und stellen Sie fest, dass der Ausgang funktioniert; starten Sie dann das Spiel und prüfen Sie zusätzlich, woher der Verkehr tatsächlich hinausgeht. Das Öffnen eines einzigen Bildschirms als Beweis für die gesamte Einrichtung zu nehmen, ist die gemeinsame Quelle aller falschen Erwartungen auf dieser Seite.