[EM4] Multiplayer mit IPv6

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • [EM4] Multiplayer mit IPv6

      Wir haben den Multiplayer von Emergency 4 untersucht und kümmern uns um die nächste große Schwachstelle: IPv6.
      2006 war IPv6 quasi nicht genutzt, kein Grund für die Entwickler es damals zu berücksichtigen.
      Wir können das lösen (ein Prototyp in Nodejs ist fertig), brauchen dafür aber ein externes Tool "Proxy".

      Die Funktionsweise ist sehr einfach:
      EM4 Client -> IPv4 -> "Proxy" -> IPv6 -> "Proxy" -> EM4 Server
      Es wird aus EM4 heraus eine IPv4 Verbindung genutzt und zum Transfer über das Internet auf IPv6 umgerüstet.

      Stößt dieses Projekt bei euch auf Interesse?
      Sollten wir das als Standalone oder als Teil von EmergencyX (derzeit so geplant) veröffentlichen?

      Wie immer: Wir freuen uns über jede Mithilfe, einfach kurz melden :stick:

      :santa:


      [EM5] Emergency Explorer | [EM4] Masterserver | Das Original mit dem Blubb
    • Hey, tatsächlich habe ich am Feiertag wieder ein bisschen mit der Thematik rumgespielt. Änderungen an Em4 sind nicht wirklich praktikabel, also müssen wir außenrum arbeiten, was manche Sachen komplizierter als gehofft macht.

      Probleme entstehen, weil Internetanbieter einem Router zuhause zunehmend keine öffentliche, eigene IPv4 Adresse zuordnen, sondern diese Verbindungen über NAT laufen. Em4 berücksichtigt das leider nicht und erwartet eingehende Verbindungen auf einem festen, selbstgewählten Port, was durch NAT aber nicht mehr einfach so möglich ist.

      Em4 fragt eine API (=Versix) nach der Adresse des aktuellen Matchmakingservers (=Master). Den für diese API benötigten Server stellen wir vom EMX Team auch weiterhin über IPv4 zur Verfügung.

      Nun fragt Em4 den Master nach einer Auflistung aller aktuellen Sessions. Diese Anfrage wird als UDP Paket gesendet und geht vom Client an den Master, wo wir ebenfalls eine eigene IPv4 Adresse haben und auf dem erwarteten Port lauschen können. Der Master muss daraufhin alle Sessions ebenfalls als UDP Paket zurück an den Client senden, wo ein fester Port erwartet wird. Und genau dort kommt uns das NAT in den Weg. Aber es gibt einen kleinen Trick: Manche NATs speichern für eine kurze Zeit das Portmapping und da die Anfrage an den Master vom "korrekten" Port ausgeht, können wir in den meisten Fällen über die NAT kommunizieren.

      Nun fragt Em4 jeden Host einer Session in dieser Antwort noch einmal selbst, etwa um die Latenz zu bestimmen. Also muss jeder Host eine eigene IPv4 Adresse zur Verfügung haben, damit auch er das Paket über UDP empfangen kann, wo es jetzt eben Probleme gibt.

      Also Serverbrowser ist soweit okay, aber dann wirklich in eine Session zu kommen, ist ein bisschen schwieriger.
      Boah, das ist echt nicht einfach zu erklären, es ist leider sehr technisch und vor allem, weil ich selbst nicht alle Bausteine wirklich gut kenne :D

      Einfach um zu testen, was denn so geht, hatte ich ein ganz einfaches Experiment gebastelt, das sah dann etwa so aus: gitlab.com/snippets/34219
      UDP Port 12345 ist eine Art Infokanal für Sessions, das eigentliche Spiel wird dann über TCP Port 58282 abgewickelt. Das Experiment lauscht auf dem IPv4 Loopback und könnte diese Pakete nun auf was auch immer für einem Weg zum Host transportieren, wo sie dann ebenfalls wieder vom Loopback an Em4 übergeben werden können. Das kann man so für einen Test mal aufsetzen, aber ich hätte lieber etwas ein wenig handfesteres für euch.

      Jetzt müsste man aber alle bei der Antwort vom Master schon die IP Adressen auf Loopback und einen neuen Port umschreiben. Hier mal ein Beispiel von so einer möglichen Antwort des Masters:

      Für zwei Spiele (EMX1 und EMX2) sieht die Antwort dann verkürzt so aus:

      Source Code

      1. server_name=EMX1 (noBlubb);server_addr=192.168.1.1;server_port=58282
      2. server_name=EMX2 (noBlubb);server_addr=192.168.1.2;server_port=58282
      Diese Antwort vom Master schon bearbeiten zu lassen, ist aber leider keine gute Idee, denn dann müssen wir bei jedem Client wissen, ob die die Bearbeitung erfolgen soll oder nicht.

      Ich hatte gehofft, vielleicht über das LAN Feature noch ein paar Spiele "reinschummeln" zu können, indem der "Proxy" aus diesem Projekt einfach auf die Anfragen von Em4 im Netzwerk antwortet, obwohl er auf der selben Maschine läuft. Das funktioniert leider nicht, weil Em4 nicht immer die beste Netzwerkschnittstelle auswählt (bei mir zum Beispiel ein Netzwerkinterface einer VM, das die lokale Maschine nie verlässt). Falls das funktioniert, wird der Broadcast wirklich im Netzwerk gesendet, leider an den selben Port, auf dem Em4 auch noch eine Antwort erwartet. Starte ich dort ein eigenes Programm, initialisiert Em4 den Multiplayer nicht korrekt. Mit dem Broadcast im LAN und einer App auf meinem Handy kann ich tatsächlich diese Pakete sehen und könnte nun auch eigene Sessions zurücksenden. Aber wirklich toll ist das ja nicht :D Also bliebe die Option alle Pakete, die übers Netzwerk gesendet werden, mitzulesen und auf die von Em4 getrennt zu reagieren, was ich aber auch nicht gerne mag.

      Also als Beispiel sollte die Antwort dann etwa so aussehen:

      Source Code

      1. server_name=EMX1 (noBlubb);server_addr=127.0.0.1;server_port=30001
      2. server_name=EMX2 (noBlubb);server_addr=127.0.0.1;server_port=30002
      und am Loopback (127.0.0.1) würde dann eben der Proxy die Sessions nun getrennt nach Port aufnehmen und an die entsprechenden Hosts weiterleiten:
      127.0.0.1:30001 -> 192.168.1.1:58282
      127.0.0.1:30002 -> 192.168.1.2:58282

      TL;DR:
      Ist mit einiger Bastelei verbunden und nachdem es hier ruhig blieb, habe ich das so als Seitenprojekt ohne Priorität etwas schleifen lassen. Falls du da Interesse hast, gucke ich da gerne nochmal drüber und falls jemand hier vorbeikommt und gerne mitbasteln würde oder ich da was ganz falsch verstanden habe, sagt bescheid :D


      [EM5] Emergency Explorer | [EM4] Masterserver | Das Original mit dem Blubb