Featurewünsche für LegacyClonk

Hole punching ist schon implementiert?
Ich schlug ja keine NAT-Traversal Implementation vor, sondern “nur” eine Überprüfung, ob der vom anmeldenden Host angegebene Port (TCP und UDP) von außen erreichbar ist. Ob der Masterserver also tatsächlich mit einem Clonk-Client spricht (oder meinentwegen reicht notfalls auch bei TCP zu prüfen, ob es ein SYN-ACK gab). Wenn der Test fehlschlägt, kann man das ja entsprechend an den Client (der die Verbindung parallel ja auf DPort 443 aufgebaut hat zurückgeben)

Ich mein, ich sehe doch die ganzen 2er-Spiele, die wahrscheinlich noch Hamatchi o.ä. nutzen, bei denen man partout nicht joinen kann.

Hole Punching ist in OC schon implementiert und dürfte einfach zu portieren sein. Was du vorschlägst, ist in jedem Fall eine Neuentwicklung.

Benötigt aber nur eine IPv4 :stuck_out_tongue_winking_eye: und sollte in allen Fällen ein korrektes Ergebnis zurückgeben. Ist halt weniger unter “NAT-Durchdringung” sondern eher unter “Analyse” einzuordnen

Es gibt bereits CREMA, das kann immerhin den TCP-Part überprüfen.

1 „Gefällt mir“

sollte in allen Fällen ein korrektes Ergebnis zurückgeben

Nein, eben nicht. Wenn jemand keine Port-Weiterleitung eingerichtet hat, NAT/Firewall aber Hole Punching zulassen, ist das Ergebnis deines Vorschlags nicht korrekt. (Übrigens auch schon mit dem netpuncher, den CR so wie es ist unterstützt.)

Du findest meinen Vorschlag (Benutzern, die ihre Firewall(s) nicht richtig konfiguriert haben eine Meldung anzuzeigen) also nicht gut, weil die Erkennungstechnik (Portcheck) mit einer noch nicht implementierten Technik (Hole Punching), welche das Verbinden zum Host in nicht allen Fällen und nur über UDP ermöglicht nicht gut, weil diese Erkennungstechnik nicht mit Hole Punching kompartibel wäre und es zu fehlerhaften Meldungen kommen könnte?
Verstehe mich nicht falsch, ich habe nichts gegen Hole Punching es ist für mich aber keine optimale Lösung:

  • Ich schließe keine Kombination der Techniken aus, wo eine UDP-Verbindung auch durch den Hole Puncher getestet wird.
  • Wir haben bereits CREMA (Danke @Kanibal, davon wusste ich nichts), welches „nur“ eingebunden werden müsste (ich sag das so leicht ich weiß…)
  • Nehmen wir an, dass Hole Punching funktioniert, ändert das nichts an der Tatsache, dass der Host seine Firewall nicht ordnungsgemäß konfiguriert hat. Die Verbindung muss nicht zwingend klappen.

Eine Meldung mit fehlgeschlagenem Hole Punching und geschlossenen Ports könnte dann so lauten:

Der Masterserver [oder „Wir haben“] hat festgestellt, dass deine Firewall nicht richtig konfiguriert ist. Die von deinem Client an dem Masterserver gemeldeten Ports

  • TCP 11112
  • UDP 11113
    [wieder einrücken] sind von außen nicht erreichbar. Das Umgehen der Firewall mittels Hole Punching schlug ebenfalls fehl. Dies bedeutet, dass sich deinem Spiel aus dem Internet kein Spieler anschließen kann, da du von außen nicht erreichbar bist. Lokale Mitspieler in deinem Netzwerk sind davon nicht betroffen [hier z.B. Fußnote mit Mousehover „Gilt nur, sofern deine PC-Firewall die Verbindungen zulässt.“]

Die entsprechende Meldung mit erfolgreichem Hole Punching und geschlossenen Ports:

Der Masterserver [oder „Wir haben“] hat festgestellt, dass deine Firewall nicht richtig konfiguriert ist. Die von deinem Client an dem Masterserver gemeldeten Ports

  • TCP 11112
  • UDP 11113
    [wieder einrücken] sind von außen nicht erreichbar. Das Umgehen der Firewall mittels Hole Punching war allerdings erfolgreich. Da du unter bestimmten Umständen für Spieler aus dem Internet erreichbar bist, können sich deinem Spiel manche Spieler möglicherweise anschließen. Lokale Mitspieler in deinem Netzwerk sind von dem Problem nicht betroffen [hier z.B. Fußnote mit Mousehover „Gilt nur, sofern deine PC-Firewall die Verbindungen zulässt.“].

Die Überprüfung darf gerne in den Einstellungen dauerhaft deaktivierbar sein, die Meldung darf gerne „für dieses Netzwerk“ (erkennbar an ARP-Table → MAC des Gateways) deaktiviert werden können.

Hole Punching sollte eine Notlösung für unseren Spieler X sein, der sein Routerpasswort vergessen hat und Firewalleinstellungen mangels technischem KnowHow sowieso nicht hinbekommt.

Edit: habe nochmal gesucht und es doch gefunden:

By default, Clonk uses port 11112 TCP and port 11113 UDP for game connections. For best speed it is recommended to forward both of these ports through your router or firewall.

https://wiki.openclonk.org/w/FAQ

An der Stelle sind wir wohl geteilter Meinung. Idealerweise sollte meiner Ansicht nach alles einfach so funktionieren, ohne dass der Spieler irgendwelche Konfiguration verändern muss. Manuelle Konfiguration sollte die Notlösung sein. Heimanschlüsse, wo man am Router sinnvoll etwas konfigurieren kann sind dank DS-Lite und anderen CGNAT-Verfahren sowieso am aussterben. Deshalb denke ich auch, dass Entwicklungszeit besser bei der Verbesserung der Hole Punching-Verfahren aufgehoben ist.

Die entsprechende Info aus der OpenClonk-Wiki ist nicht falsch - die Ports entsprechend freizuschalten kann durchaus sinnvoll sein, ist aber auch nicht unbedingt notwendig.

Aber wir sind hier sowieso eigentlich bei LegacyClonk, wofür du nicht mich überzeugen musst. Vielleicht baut’s ja jemand dafür.

Das sollte auf alle Fälle immer das höchstpriorisierte Ziel sein, sofern es irgendwie möglich ist.

Abgesehen davon hat es sich als unglaublich schwer herausgestellt, einem relativ ahnungslosen Clonk-Neuling zu erklären wie man Ports weiterleitet, damit er mit seinen Freunden zusammenspielen kann.
Dabei bekommen wir da wohl auch nur den Teil mit, der es in den IRC schafft.

Das einzige was mir an der „Hole-Punching wirds schon richten“-Einstellung nicht gefällt ist, dass es meines Wissens nach als unmöglich angesehen wird, zwischen zwei symmetrischen (hoffentlich habe ich den richtigen Begriff in Erinnerung) NATs zu punchen und generell ein symmetrisches NAT auf Host-Seite alles ziemlich verkompliziert.

Ich weiß zwar nicht wie das im Allgemeinen aussieht, aber angenommen ich hab meine manuellen Experimente sinnvoll durchgeführt und richtig interpretiert, sind sowohl das NAT das der Router vom A1-Festnetzanschluss zuhause macht (Port-Forwarding geht aber), sowie das NAT, über das mein mobiles Internet läuft symmetrische NATs.

Allerdings hab ich noch nicht probiert ob OCs-Hole-Punching bei diesen NATs funktioniert.
Das werde ich eventuell irgendwann noch nachholen.

Hmm da habt ihr auch wieder recht.

Gehe ich richtig in der Annahme, dass mit IPv6 Unterstützung das NATten wegfiele und somit in einem SoHo-Netzwerk die einzige Hürde die lokale Firewall wäre? Ich hab halt etwas Bauchschmerzen eine Verbindungstechnik zu nutzen, die bei manchen funktioniert und bei manchen nicht.

Ja, genau. Kein NAT mehr, es muss nur noch die Firewall überwunden werden, was aber zumindest für UDP exakt genauso funktioniert wie die NAT-Durchquerung. TCP dürfte mit IPv6 sogar auch machbar sein, das habe ich aber noch nicht implementiert. (Mit IPv4 braucht man da Heuristiken zur Portvorhersage.)

Du hast aber recht, dass es kein Wunderheilmittel ist. Ich würde es eher als eine Ergänzung sehen, die es zusätzlichen Spielern ermöglicht, online zu spielen (eben die Spieler, bei denen die NAT-Durchquerung nicht klappt, aber die einen IPv6-Anschluss haben). Diese Gruppe ist zugegeben aktuell nicht groß, das wird sich aber mit der Zeit bestimmt ändern (IPv6-Verwendung steigt, während die IPv4-Adressen knapper werden).

Jetzt sind wir auf einem Nenner :slight_smile:
Ist es technisch möglich, dass LC Blockierregeln der Firewall für eingehende Verbindungen erkennt? Weil das wäre dann die letzte Hürde, die ich noch sähe.

Keine Ahnung, ob das aktuell immer noch so ist: Unter Windows hat sich CR immer aufgehängt (OpenGL), wenn die Firewall was wollte. Dann musste man den Prozess blind per cmd killen und die Firewallregel bestätigen.

Featurewunsch #7 von Funni: Autorenfeld in den Einstellungen.
Da die Registrierprüffunktion außer Kraft gesetzt ist, gibt es keinen Autor mehr, insbesondere beim Abspeichern von Spielständen. Ein Feld in den Einstellungen zum Eingeben eines Autornamens wäre nicht schlecht. Standard könnte der Benutzername des Rechners sein. Da der Editor davon nicht betroffen ist, kann das ja hinten angestellt werden.

Featurewunsch #8 von Funni: Auto-Nicht-Bereit
Aus aktuellem Anlass: Wenn man aus dem Spiel für eine Zeit von sagen wir mal 20 Sekunden raustabbt oder der Bildschrimschoner reingeht sollte der Client als nicht mehr Bereit gekennzeichnet sein.

Auch könnte die Runde automatisch starten sobald alle Teilnehmer “Bereit” aktiviert haben, den Host zum Abbrechen des Timers und /start 0 zu zwingen ist unnötig und kann von der Engine abgenommen werden.

1 „Gefällt mir“

Featurewunsch #9 von Funni: Hintergrundbild des Packs auf allen Clients…
…sobald sie das Pack geladen haben. Sollte doch machbar sein.

EDIT: Steht bereits auf @Fulgen’s Todoliste

Dann braucht der Host aber auch einen Bereit button und Clients ohne Spieler dürfen nicht beachtet werden.

Steht auf meiner Todoliste.

das kann man daran koppeln ob der Timer zum Rundenstart aktiv ist oder nicht - nur wenn ein Timer läuft, würde das Bereit-Signal aller Clienten den sofortigen Start auslösen.

Der Host benötigt keinen Bereit-Button - da er den Timer angestoßen hat ist er offensichtlich bereit.
Dafür könnte beim Host der Runde starten-Button blinken wenn bei inaktivem Timer alle Clienten Bereitschaft signalisieren.

Auf Nicht-Legacy Clonk-Spieler braucht man dabei keine Rücksicht nehmen da man mit ihnen sowieso nicht spielen kann.

Ahso, hatte das so verstanden, dass der Timer automatisch startet. Dann ist meine Aussage natürlich murks, aber trotzdem dürften Clients ohne Spieler nicht beachtet werden oder? Der Host startet ja nicht sofort, sodass jeder Zeit zum joinen haben sollte.

wenn ein Timer läuft, würde das Bereit-Signal aller Clienten den sofortigen Start auslösen.

Was ist dann der Sinn des Timers?