Descentforum.DE

Munk · Last edited by Floyd on 10.04.2005, 13:53; edited 1 time in total

karx11erx · Posted: 10.04.2005, 01:25 Post subject:

Hey Munk,

wäre super! Sehr glücklich

Die Schnittstelle müsste recht einfach aussehen:

Datenpaket "Server":
- Kennung "Server"
- IP-Adresse + Port (6 Bytes)
- Level-Name (Text, sagen wir 40 Bytes)
- Spieltyp (Text, 20 Bytes)

Wenn der Tracker diese Daten erhält, merkt er sie sich eine gewisse Zeit lang. Der Client muss regelmäßig refreshen (alle X Sekunden, X sinnvoll (keine Ahnung, was sinnvoll ist - 30 Sek?)

Datenpaket "Client":
- Kennung "Client"
- Server-Zähler z

Wenn der Tracker diese Daten erhält, sendet er die Server-Daten des z-ten Servers in seiner Liste an den Client zurück. Ist z > Anzahl beim Tracker gemeldete Server, nullt er einfach alle Felder ausser der Kennung "Server" aus.

Da UDP/IP in D2X-W32 drin ist, aber nicht TCP/IP, würde ich das latürnich gerne per UDP/IP machen.

Kannst Du damit was anfangen?

Aga · Posted: 10.04.2005, 08:35 Post subject:

Und wenn es geht, noch die Anzahl der Gamer an den Tracker melden.

Aga

Munk · Posted: 10.04.2005, 08:52 Post subject:

Um auf Agas Frage einzugehen:

@Karx: Probet der Client dann den Server selbständig nochmal nach Level und Spieltyp, nachdem er die Antwort vom Tracker erhalten hat ? Denn selbst 30 Sekunden sind eine laaaaange Zeit.
Man stelle sich mal vor, der Server hat sich im Level geirrt, und startet fix einen neuen, der Client hat aber nur die alten Daten.
Dann würde der Client ja auch gleichzeitig die dann aktuellen Spielerzahlen vom Server direkt erhalten.

Als Server/Client-Kennung würde ich einfach ein simples 0x53 bzw. 0x43 nehmen - also den Character "S" und "C". Auf diese Weise ist dann auch hoffentlich die Bedeutung einleuchtender, wenn jemand das Protokoll analysieren will (warum auch immer).

Gib mir aber ein paar Tage Zeit dafür. Meine Wahl der Instrumente würde instinktiv auf ein PERL-Skript fallen. Allerdings hab ich noch nie mit PERL gearbeitet, geschweige denn mit Socketkommunikationen.

Munk · Posted: 10.04.2005, 09:44 Post subject:

So ganz durchdacht scheint das noch nicht zu sein.

Edit:
Das Format des clientseitigen Serverzählers ist ja noch nicht geklärt.
Da Perl leider Schwierigkeiten hat, aus Zeichen deren ASCII-Wert zu bestimmen (ord() kann nur von 0-127), schlage ich vor, den Zähler textkodiert zu übermitteln (ist dann in meinen Augen auch portierbarer).
4 Stellen (für 10000 Server) sollten denke ich dicke reichen, der Einfachheit halber mit führenden Nullen, so daß das Feld immer gleichlang ist.
Also als Serverzähler dann von "0000" bis "9999".
Anfragen, die nicht diesem Schema gehorchen, werden ignoriert.

Dann ist folgende Sache mir noch aufgefallen.
Der Client soll ja den Serverzähler einfach hochzählen, und als Antwort die jeweiligen Serverdaten bekommen.
Nun kann (und wird!) es aber passieren, daß während dem Hochzählen des Clients ein laufender Server einen Timeout erfährt, wodurch sich ja dann die Serverzahl verringert, und die nachfolgenden Server im Tracker eine Position nach unten wandern.
Nun zählt der Client aber fröhlich weiter: Die Folge ist, daß er dann einen Server ausgelassen hat.

karx11erx · Posted: 10.04.2005, 15:49 Post subject:

Statt eines Zählers wäre auch ein "Get First Server" und ein "Get Next Server"-Aufruf denkbar. Das Problem ist dann aber, daß sich der Tracker für jeden Client merken muß, wo er gerade steht.

Andererseits gibt es eine max. Anzahl X an Servern, die ein Client sehen kann, also wäre es auch möglich, dem Client einfach die X ersten Server zu schicken (wenn X < max, einfach X+1 bis max. ausnullen).

Theoretisch sieht der Client zwar dann nicht alle Server, aber praktisch spielt das denke ich bei D2 keine Rolle.

Aga hat Recht, Anzahl Spieler sollte auch in den Info-Paketen vom Server drinstehen.

Woran ich dachte ist, daß z.B. Vortex irgendwann auch D2-Spiele zeigt und man mit Doppelklick eines starten kann, da können die Server-Listen dann beliebig groß sein. Wenn das keine Option ist, würde es sogar reichen, wenn der Tracker ausschließlich die IP-Adressen und Ports der Server vorhält und bei Anfrage abschickt. Die Clients melden sich dann selbständig bei den Servern und fragen alles weitere ab (das ist in D2 ja schon drin). Für den Anfang würde das eigentlich schon völlig ausreichen.

Die diversen Paketkennungen mache ich wie es Dir reinpaßt. Sag einfach, wie Du's willst.

Statt 30 Sekunden kann man auch weniger nehmen, mir macht das nix aus (meinetwegen auch 1/20 Sekunde ...).

Munk · Posted: 10.04.2005, 16:16 Post subject:

Ein ausgefeilteres Trackersystem, der den Traffik zum Spieleserver so gering wie möglich hält, wäre zwar wohl besser und eleganter - aber bei den handvoll D2-Servern wohl ein wenig übertrieben.

Die Sache ist nur folgende:
Mir wäre es lieber, wenn sämtliche spielrelevanten Daten der Client selbst beim Server abfragt, und der Client nur die Serveradressen vom Tracker bekommt.
In D2X ist doch sowieso schon ein Gamebrowser eingebaut (für das Lan), oder nicht ?
Da bräuchte man doch nur eine Kleinigkeit ändern: statt die Inforequest-Pakete an die Broadcastadresse zu schicken, schickt man sie an alle Adressen, die der Tracker nennt, und braucht nur auf die eintrudelnden Antworten warten.

karx11erx · Posted: 10.04.2005, 21:31 Post subject:

Munk,

das habe ich selber in meinem letzten Post schon vorgeschlagen. Genau so könnte man es machen. Da D2 max. 12 Server (oder so) überhaupt anzeigen kann, kann der Tracker die Serverliste sogar auf 12 Einträge begrenzen.

DDevil · Posted: 11.04.2005, 11:58 Post subject:

Nen Tracker Rechner kann ich anbieten.

habe feste IP, was die Sache erleichtern sollte.

Ich muss nur wissen was für ein Rechner gebraucht wird, welches OS etcetc.

Bei Linux brauch ich HILFE ! Verlegen

exi · Posted: 11.04.2005, 13:20 Post subject:

Klingt toll, was Ihr hier vor habt. Das sollte D2X ganz neuen Aufwind verleihen, da KALI für viele keine Lösung darstellt. Helfen kann ich zwar nicht, aber Anfeuern kann ich Euch...

Munk · Posted: 11.04.2005, 13:21 Post subject:

Danke fürs Angebot, Devil. Aber nen Linuxrechner mit fester IP haben wir schon als VEX-Server lauffähig.

Nogly · Posted: 11.04.2005, 19:20 Post subject:

D2 über Vortex zustarten und vielleicht auch D1! Wär stark wenn Ihr das hin bekommen würdet! Sehr glücklich

Munk · Posted: 11.04.2005, 19:45 Post subject:

Wieso D1 ?
Da müßte man ja die Arbeit doppelt machen.
D2X kann ja auch D1-Missions abspielen. Da ja auch in D2 alle Waffen von D1 drin sind, sollte es dann doch kein Unterschied machen, oder ?
Also einfach all die Spiele mit D2X spielen, die dann mit D1(X) gespielt hätte.

Munk · Posted: 13.04.2005, 14:21 Post subject:

Ok Karx. Ich hab den Tracker nach obiger Spezifikation fertig.

Eine Sache habe ich jedoch noch: Bei unzulässiger Anfrage des Clients (also er fragt nach einer Servernummer, die nicht existiert) wird ersteinmal die Ergebnisfelder statt mit Nullbytes mit Leerzeichen gefüllt.
Ich kann zwar dem Programm auch sagen, er soll Nullbytes nehmen, nur kann ich damit leider nicht das Ergebnis überprüfen, da meine Konsole mir die Nullbytes nicht anzeigt. Ich weiß also nicht, ob sie korrekt gesendet werden. (eigentlich sollte das schon der Fall sein, denn Perl-Strings sind Binary-Safe).

Wenn Du auch soweit bist für ein Testlauf, sag mir über ICQ, eMail, Foren-Messages oder IRC bescheid.

karx11erx · Posted: 13.04.2005, 19:37 Post subject:

Munk,

Super!

kannst Du mir Deine genauen Specs posten?

Es reicht übrigens eine feste Serverliste mit 12 Einträgen, weil ich in D2X sowieso nicht mehr anzeigen werde.

Es gäbe also einen Server-Aufruf "hier bin ich" und einen Client-Aufruf "gib mir Server-Liste mit 12 Einträgen" (leere Einträge geblankt, das ist ok).

Ausserdem muss ich wissen, ob Du nun ASCII-Daten (Text) erwartest und verschickst, oder binäre.

karx

Munk · Posted: 13.04.2005, 20:44 Post subject:

Ok, hier nun die Specs vom Tracker:

Zum Eintragen eines Spieleservers in den Tracker sendet der Server ein UDP-Paket an einen ausgemachten Port:
"S" <IP Binär, 4 Bytes> <Port Binär, 2 Bytes> <Data Binär, 60 Bytes>
Insgesamt also genau 67 Bytes, nur dann ist es gültig.
Wie der Spieleserver den Datenblock nutzt, ist dem Tracker prinzipiell egal. Spieleserver und Spieleclient sollten sich halt nur in Format und Bedeutung einig sein.

Ein eingehendes gültiges Paket mit identischen IP+Port-Feldern überschreibt einen vorhandenen Datensatz wieder.

Der Datensatz verfällt nach 30 Sekunden der letzten Aktualisierung.

Das Lesen des Trackers ist einfach:
Der Client schickt eine UDP-Paket mit dem Inhalt
"C" <Datensatznummer, 4 Bytes>
Also genau 5 Bytes. Die positive Datensatznummer besteht aus den Ziffern 0-9, welche als Text nach ASCII-Norm kodiert sind, mit führenden Nullen. Der erste Datensatz hat die Nummer 0000, der letzte theoretische Datensatz hat die Nummer 9999.
Existiert ein Datensatz nicht, so existieren alle Datensätze mit größerer Nummer ebenfalls nicht!

Die Antwort des Trackers daraufhin, gesendet als UDP-Paket an dieselbe IP und denselben Port der zuvor geschickten Anfrage, ergibt bei Erfolg:
"S" <IP Binär, 4 Bytes> <Port Binär, 2 Bytes> <Data Binär, 60 Bytes>
Dies ist also einfach dasselbe Paket, was der Server zuvor an den Tracker gesendet hat.
Im Fehlerfall, die Datensatznummer existiert nicht, erhält der Client:
"S" <Leerzeichen, 66 Bytes>
Leerzeichen wie nach ASCII-Norm.

Die Datensätze sind in ihrer Reihenfolge nicht als nach etwas sortiert spezifiziert.
Tatsächlich sind sie in der jetzigen Implementierung nach IP-Adressen+Port aufsteigend sortiert, dies kann sich in zukünftigen Implementierungen aber ändern.

----

Anmerkungen:

Im Grunde kann man das Datenfeld auch auf 64 oder mehr Bytes ausdehnen.
Wie der Server oder Client jetzt dieses nutzt, ist ihm selbst überlassen. Mein Vorschlag wäre über den Inhalt:
Versionsnummer des Servers
Levelname
Modname
akt. Spielerzahl
Gesamtspielerzahl

Ein weiteres Problem ist die Antwort des Trackers.
Beim Eintragen in den Tracker erfolgt kein ACK als gesendetes UDP-Paket.
Die Antwort des Trackers an den Client erfolgt anhand dessen Querypaket-Signatur, die Antwort wird also an die IP und an den Port(!) geschickt, der lokal beim Client verwendet wurde.
Inwiefern diese Antwort durch NAT etwa von einem Router gestört wird, kann ich nicht beurteilen.

Den Paketinhalt im Fehlerfall können wir von Leerzeichen auch mal auf Nullbytes testen. Da weiß ich leider nicht, ob es funktioniert (hab gerade kein Perl-Debugger zur Hand).

IP und Port des Trackers sollten natürlich vom Client und Server aus konfigurierbar sein.

Da die Daten des Servers nach 30 Sek. gelöscht werden, sollte der Server am besten alle 10 Sek. den Tracker updaten.

Wenn Du ein Test starten willst, so sag mir bitte bescheid, da beim Test noch Debug-Code drinsteckt, und ich gerne dessen Ausgaben beobachten möchte.

karx11erx · Posted: 13.04.2005, 22:00 Post subject:

Munk,

nach unserem Chat hier mein Formatvorschlag:

Der Server schickt ein Paket mit 7 Bytes Länge: 'S'<IP:4 Bytes><Port: 2 Bytes>

Der Client schickt ein Paket mit 1 Byte Länge: 'C'

und erhält als Antwort ein Paket mit 512 Bytes Länge: 'S'<Anzahl Einträge><IP:Port 1>...<IP:Port 85>

Wobei

<IP:Port> jew. 6 Bytes lang sind
<Anzahl Einträge> gibt an, wieviele der Tabelleneinträge tatsächlich belegt sind. Die Tabelle muß ab dem ersten Eintrag "dicht" (d.h. ohne Lücken) belegt sein.

Die nicht belegten Tabelleneinträge können ausgenullt sein, ist aber egal, da ja <Anzahl Einträge> schon angibt, wie weit der Client die Tabelle auswerten muss.

512 Bytes hätte ich gerne als max. Tabellenlänge, weil ich das in D2X mit einem Datenpaket abhandeln kann. Da passen 85 Server rein, das sollte angesichts der heutigen Popularität von D2 ausreichen. Winken

Ich will keine Acks, UDP ist ja verbindungslos.

Da sich die Server eh min. alle 30 Sek. melden müssen, ist ein Ack nicht nötig.

Der Client meldet sich auch periodisch wieder, also ditto Daten verschicken ohne Rücksicht auf Verluste.

Munk · Posted: 14.04.2005, 20:15 Post subject:

So, die Änderungen sind ja nur minimal.

Der Kerl läuft zum Testen unter
81.169.162.145:9424

Viel Glück!

karx11erx · Posted: 14.04.2005, 22:47 Post subject:

Munk,

der Kerl redet nicht mit mir. Traurig

Ich kriege zwar ne Antwort vom Tracker, aber keine Daten, sondern eine Fehlermeldung: 10054, 'Connection reset by peer'. Der mag meine Anfragen nicht. Kann auch sein, dass Dein Script bei Anfragen abstürzt. Hast Du es getestet?

Ich bräuchte übrigens noch eine Änderung bei den Server-Daten:

Hier soll nur ein 1-Byte-Datenpaket mit der Kennung 'S' verschickt werden, und der Tracker soll IP-Adresse und Port aus der Absenderadresse des Datenpakets ermitteln (die Absenderadresse bekommt man normalerweise von der Empfangsfunktion zusätzlich zu den Daten mitgeliefert). Es gibt nämlich Fälle, wo D2X die Server-Adresse nicht korrekt ermitteln kann (z.B. Router, NAT). Geht das?

Ich habe in d2x-w32.zip auch ein d2x-w32-dbg.exe reingepackt. Benutze d2x-w32-dbg.exe, gehe auf Multiplayer, Join UDP/IP game, dann fängt das Programm an, die Serverliste von Deinem Tracker abzufragen.

In d2x-w32-dbg habe ich einen fundamentalen Fehler in der Behandlung der Player Files durch D2X-W32 behoben. Du kannst Deine alten Player Files deshalb nicht mehr damit verwenden und mußt ein neues anlegen. (Dafür sind die Player Files in Zukunft wieder rückwärts-kompatibel ... Sehr glücklich

)

karx

Munk · Posted: 15.04.2005, 06:39 Post subject:

Sag mir mal bescheid, wenn Du online bist.

Natürlich habe ich es getestet, zumindest was den Tracker betrifft. Der Tracker verschickt die Antwort an Peer-IP+Port des Requests.

Bei UDP kenn ich mich nicht so gut aus, schließlich ist es verbindungslos. Wie kann dann die Verbindung abgebrochen werden ?

Da D2X bei mir nicht läuft, werde ich auch mit deiner Debugversion wenig anfangen können.