verschiedene Ports per Subomain ansprechen

[cider23]

Hallo,

bei einer Projektarbeit in der Ausbildung versuchen wir mehrere gleiche Gameserver (hier Beispiel Minecraft) auf ein und demselben Host laufen zu lassen. Diese werden natürlich auf verschiedene Ports konfiguriert.

Im Spielclient müsste man nun domain.de eingeben, um auf den Standard-Port zuzugreifen. Will man die anderen Instanzen erreichen, muss man die Ports dazugeben domain.de:1337 mal als Beispiel.

Wir wollen nun, dass die Portauflösung über die Subdomain realisiert wird:
server1.domain.de wird aufgelöst zu domain.de:1337, server2.domain.de wird aufgelöst zu domain.de:1338 usw...

Ich war eine Zeit lang krank und der Schülergruppe heute zugeteilt. Leider ist morgen die letzte Möglichkeit das grade zu biegen und die Idioten dümpeln nur rum... ich mag mir aber nicht die Note versauen...

Die Nachbargruppe hat es (allerdings auf einem Linux) mittels NAT und Routingtabellen gebogen. Unter Linux hätte ich auch Ansatzpunkte, aber bei Windows bin ich komplett aufgeschmissen.

Kann mir dabei jemand helfen oder zumindest Tips geben, wie ich es bewerkstelligen kann?

Ich bin für jede hilfreiche Antwort dankbar.

 

[TerraX]

Mir fallen 2 Ansätze ein. Klassischerweise würde man einen Reverse Proxy nehmen, der je nach angefragter Domain auf den entsprechenden backend-Service umleitet. Allerdings reden wir hier von Minecraft und ich kenne nur Reverse Proxies für das HTTP-Protokoll. Damit scheidet das vorerst aus.

Alternative 2: Man hängt jeden Minecraftserver auf eine andere IP (vergiss nicht Du kannst mehrere IPs auf eine Maschine hängen). Damit kann sogar der Standard-Port bleiben. Via A-Record im DNS kannst Du dann bequem die entsprechenden Zuweisungen vornehmen:

srv01.game.net -> 10.8.0.1
srv02.game.net -> 10.8.0.2
...

 

[d4f]

Dein Versuch ist technisch nicht realisierbar. Minecraft verwendet UDP, welches im OSI-Modell unter der Applikationsebene und somit Domain-IP Zuordnung liegt. So etwas wie Domains kennt das Internetprotokoll nämlich schlicht gar nicht.

Theoretisch wäre es möglich über ein client-seitiges Zusatz-Tool die Verbindung um zu biegen oder dem Spiele-Client die Fähigkeit (zB mit TXT-Felder in der Zone) bei zu bringen aber ohne client-seitige Änderung ist leider Fehlanzeige.

 

[TerraX]

Dein Versuch ist technisch nicht realisierbar. Minecraft verwendet UDP, welches im OSI-Modell unter der Applikationsebene und somit Domain-IP Zuordnung liegt. So etwas wie Domains kennt das Internetprotokoll nämlich schlicht gar nicht.

Korrigiere mich gern, wo mein Denkfehler liegt. Aber bevor der Client ein Verbindung aufbauen kann, muss ja erstmal der Name des Servers aufgelöst werden.

Viele andere Games, nicht nur Minecraft, verwenden UDP und die namensbasierte "Ansprache" von Gameservern. Insofern müsste der 2. Ansatz über entsprechende DNS-Einträge eigentlich funktionieren.

 

[d4f]

Korrigiere mich gern, wo mein Denkfehler liegt. Aber bevor der Client ein Verbindung aufbauen kann, muss ja erstmal der Name des Servers aufgelöst werden.

Ja. Es wäre theoretisch machbar dass ein Nameserver auf dem System mit TTL 1 Sekunde Anfragen beantwortet und die nächste einkommende UDP-Verbindung auf den Haupt-Port auf den Gameserver per Firewall umleitet. (UDP ist zwar stateless aber für Kommunikationen wird generell ein gleichbleibender Socket, also Source-Port, verwendet)
Hier gibts nur ein Problem... dein Rechner fragt rekursiv beim Router, der Router beim Provider und dieser, mit eigener IP, beim Nameserver an. Somit würde die falsche IP "freigeschaltet" werden.

Viele andere Games, nicht nur Minecraft, verwenden UDP und die namensbasierte "Ansprache" von Gameservern.

UDP wird generell verwendet weil es eine niedrigerere Latenzzeit hat (kein ACK notwendig) und der Verlust eines oder mehrer Pakete kein Problem darstellt. (wenn der Client das TCP-Paket erhalten hätte wäre es eh veraltet). Ausserdem sind die generell kritischsten Teile der Verbindung gegen Korruption und Verlust geschützt, im DSL-Netz wäre das der Interleaved Algorithmus. (Ausser natürlich bei den Leuten welche gegen teures Geld den Algorithmus abschalten lassen)
Allerdings sind alle IP-Layer basierten Protokolle, sei es bsp. UDP oder TCP, NICHT domain-kennend; sie kennen nur Source- und Destination-IP sowie die MAC-Adressen im aktuellen Netzabschnitt. Hier sprechen wir vom Äquivalent des OSI-Layer 4

DNS hingegen liegt im Application layer (OSI-Layer 7), also bedeutend "höher" (abstrakter). Alle DNS-basierten Dienste _müssen_ somit ebenfalls im OSI-Layer 7 liegen oder höher (wobei der inoffizielle "Layer-8" der Benutzer ist)

 

[TerraX]

...Allerdings sind alle IP-Layer basierten Protokolle, sei es bsp. UDP oder TCP, NICHT domain-kennend; sie kennen nur Source- und Destination-IP sowie die MAC-Adressen im aktuellen Netzabschnitt. Hier sprechen wir vom Äquivalent des OSI-Layer 4 ...

Öhm, entweder reden wir beide aneinander vorbei oder einer von uns beiden hat die bisherigen Beiträge des anderen nicht richtig gelesen oder einer von uns beiden hat sich total verrannt.

Beispiel: Nehmen wir eine UDP-basierte Anwendung wie TS3 oder Mumble (die können auch über TCP) oder Counterstrike.

Ich richte eine TLD-Domain ein namens gamserver.net. Darunter setze ich A-Records für:

srv01.gameserver.net => 10.8.0.1
srv02.gameserver.net => 10.8.0.2

Auf dem Server, wenn ich es ganz klassisch mache, richte ich 2 VMs ein mit den beiden o.g. IP-Adressen inkl. entsprechendes Routing zwischen Host und VMs. Auf den VMs richte ich die Gameserver ein und binde sie entsprechend an die einzelne individuelle IP-Adresse. Alternativ starte ich mehrere Instanzen auf der gleichen physischen Maschine und binde sie aber (sofern es die Config hergibt) an die entsprechende IP-Adresse. In beiden Fällen kann ich den Standard-Port für die Anwendung aka Game belassen.

Jetzt geht der Spieler los und startet seinen Game-Client, öffnet den Server-Browser und tippt den Namen ein. Also srv01.gameserver.net. Der Client rennt los und besorgt sich über DNS die zum Namen passende IP-Adresse.

Jetzt erst wird der eigentliche Verbindungsaufbau zum Gameserver gestartet nämlich mit der nun bekannten IP-Adresse, was ja genau nach Deinen Informationen über TCP/UDP problemlos möglich ist.

Last but not least, Du spielst nicht oft, oder?

 

[d4f]

Ja sicher funktioniert das, du brauchst aber dazu keine VM, generell sind (fast) alle Applikationen dazu imstande auf nur einer IP/Port Kombination statt auf allen IP's zu lauschen.
Generell wird man dafür aber keine IP's kriegen, da die Bequemheit der User für RIPE vermutlich keinen Grund zur Vergabe darstellt Und von IPv6 sind geschätzt 99.99% der Gameserver meilenweit entfernt.

Mein "Dein Versuch ist technisch nicht realisierbar" war an den TE gerichtet, jetzt wird mir klar dass du das auf deinen Vorschlag bezogen hattest. Tut mir leid für die Verwirrung.

Last but not least, Du spielst nicht oft, oder?

Nur TF2 um Stress ab zu bauen =) Aber die generelle Gaming-Techniken sind mir schon bekannt, ich habe lange genug Hoster betreut und auch damals an "Stabilizer" für die infamose 1000fps CSS-Gameserver gearbeitet.

 

[TerraX]

... auch damals an "Stabilizer" für die infamose 1000fps CSS-Gameserver gearbeitet.

Ich habe für 3 LAN-Parties mit 120-320 Gästen die Gameserver installiert und betreut. Und davor einige kleinere mehr. Ich sage dazu nur: SNAKEOIL!!!111!!

P.S.: Die besten Ergebnisse habe wir mit einem Placebo erzielt. Ein Standard Minimal-Debian-Image und eine Standard ESL-Konfig. Dazu etwas blabla und die Gamer waren von der "Performance" absolut überzeugt.

 

[TerraX]

Mein "Dein Versuch ist technisch nicht realisierbar" war an den TE gerichtet, jetzt wird mir klar dass du das auf deinen Vorschlag bezogen hattest. Tut mir leid für die Verwirrung...

Yepp - schon klar jetzt. Und ich hatte das gemäß dem TE auf eine experimentelle Umgebung abgestellt und da gibt es keinen IPv4-Mangel.

 

[d4f]

Und davor einige kleinere mehr. Ich sage dazu nur: SNAKEOIL

Snakeoil für den die Kunden massiv Geld bezahlen auch wenn man sie darauf hinweist dass es technisch gesehen sinnfrei ist. Aber wie gesagt, so oder so ich war Betreuung/Sysadmin; Chef will, ich tu, Chef bezahlt =)
Valve hat ja schlussendlich dem ganzen Blabla mit dem Engine-Upgrade einen Schluss-Strich gezogen.

Generell waren einige Techniken aber nicht so falsch. So weckt der Kernel oft zu spät auf und zwar um einen relativ statischen Wert. (Naja eigentlich ist der Wert recht jitter-ig aber mit einigen Techniken kriegt man ihn fast konstant) Indem man die sleep-Zeit nun korrigiert (der Gameserver ist dazu nicht imstande) kann man die Werte korrekter kriegen und damit -sehr geringfügig- Reaktionszeit, Vorhersagbarkeit sowie zeitliche Genauigkeit verbessern.
Sinnvoll sind diese Techniken somit zwar, aber nicht für Gameserver, sondern für andere Echtzeitanwendungen =)