OFP Serverliste
End of Gamespy
Zitat:
Mir fiel jetzt nix besseres ein, als die ganze Serverliste abzuknipsen. Wenn der Browser dann im Juni leer ist, hat man wenigstens ein paar Anhaltspunkte, wonach man suchen könnte. Hoffentlich kommt noch jemand mit ner besseren Lösung! :ugly: http://dl1.armed-assault.de/ofp/ofp_...e_31032014.jpg |
Von hier könnteste auch ein backup machen...
Operation Flashpoint Game Statistics - Index Die beste Lösung wäre irgendwo eine Plattform wo alles gespeichert wird. |
Ich habs da halt nicht so mit der Technik.
Wenn jemand das Konstrukt machen tut, und unser flicki das für ungefährlich einstuft, können wir gern alles hosten. Die 300kb bekommen wir noch irgendwo unter :D |
Naja das Problem is, dass sobald der Gamespymaster weg ist, du auch nicht mehr mitbekommst, welche Server es wirklich noch gibt. Die Liste kann halt irgendwann total sinnlos werden, weil keiner der Server mehr existiert.
Die Server haben sich ja direkt bei Gamespy gemeldet, so dass die ganzen Query-Skripte die es so gab/gibt immer nur den Master kontaktieren brauchten, um sich alle Server zu holen. Der Master hat die Kisten dann selbst aus seiner Liste geschmissen, wenns kein Heartbeat oder sowas mehr gab. Und die Detailqueries haste dann anhand dieser Serverliste pro Server ausgeführt um zu wissen wer drauf sitzt, welche Mission geladen/gestartet worden ist und so weiter und so fort. Nach meinem Dafürhalten lohnt der Aufwand nicht, für die 20 Server noch irgendwie ne Mechanik einzubauen, höchstens von/mit BIS. Da müsste sich jetzt hier jemand hinsetzen und nen Query + ne Server-Eintragliste basteln. Dir fehlt dann immernoch ein Autoconnect auf die Boxen (k.A ob nen Join via Param in OFP möglich war, ich glaube "The All Seeing Eye" (Gott hab auch das seelig) konnte das iwi. Außerdem musste die Server immernoch wenigstens händisch eintragen, weil die sich ja trotzdem nirgends melden können. Die Betreiber könnten natürlich versuchen die IPs zum Master umzubiegen, sodass ein gefakter Gamespymaster irgendwo lauscht, aber denn musste wieder das Protokoll analysieren wenn die Doku nicht irgendwo rumliegt. Neeeee....also mir ist der Aufwand zu fett. Nen Queryskript hätte ich noch rumliegen. Schreib doch mal Suma ne PM und frage mal, ob die OFP noch patchen dürfen. Weil wenn, dann bräuchten sie Gamespy nur rauspatchen und alles wäre easy. Den Master können wir dann gerne hosten :zahn: |
Zitat:
Es geht weiter :D |
Geht's komischerweise auch iwi so. Ich konnte gestern Abend in OFP und A2/OA noch alles querien. Jedenfalls den letzten Stand :lol:
|
Flicki, wird erst am 31. Mai abgeschaltet.
|
Dachte Ende März? Dann hat ja BI noch ausreichend Zeit LOL.
|
Hmm.. gestern Nacht 8-10 volle Server mit je ca. 20 Spielern, da tut sich ja wirklich was.
Könnte jemand nicht im Zuge dessen einen C&H Server aufsetzen mit alten Karten wie Arudy, Battlefield 1985, Anhohe, b2t, Everonwar etc.. pp) :naughty: Mir fehlen leider die technischen Möglichkeiten. |
Zitat:
Im BIS Forum hab ich auch noch mal alles übersichtlich zusammengefasst, da auf Clientseite ein Programm zum Abrufen der Serverliste benötigt wird, nämlich OFPMonitor, stammt auch von mir. Ich habs noch nicht ganz geschafft, GameSpys Protokoll dafür 1 zu 1 nach zu bauen, also verwende ich dort zur Zeit ein vereinfachtes eigenes. Und die Serverhoster müssten in der Konfig den reportingTo Einstellung ändern, um wie du schon sagtest, die Heartbeats an den richtigen Master zu schicken. Noch eine Sache zum Masterserver: Der müsste bevorzugterweise an einer statischen IP/mit Domain gehostet werden, da mir bei einem Testlauf aufgefallen ist, dass die Spielserver die Adresse des Masterservers nur beim Start einmal auflösen und dann immer die selbe IP verwenden. Zumindest wurden nach 3 Stunden die Heartbeats immer noch an die alte IP gesendet. Wenn also dann mal der Master seine IP wechselt, weil er ne dynamische hat, dann gehen die Heartbeats ins Leere. Wie schaut dann aus, hättet ihr Interesse da mitzumachen? |
Aloha. Ich hasse zwar Java, aber der Code liest sich angenehm aufgeräumt, beim mal kurz drüberlesen.
Ich hab ehrlichweise so gut wie keine Zeit, und es wäre unfair jetzt hier Unterstützungsfähigkeit vorzugaukeln. Ich finds aber schon echt stark, dass Du dich da hinsetzt und das angehst! /Me likes :) Zitat:
Vllt macht man da auch "einfach" eine Art Gesamtpaket draus, und bastelt noch einen "Beobachter" für den Server selbst. Der Beobachter könnte von außen ja dann irgendwie nen Killsignal absenden, wenn der Master nicht mehr pingbar ist, bzw. ne Mail mit dem Hinweis an den Admin schicken: "Eh starte mal deine Box neu.". Dann startet die Box neu, machtn neuen Lookup und alles wird gut. Ist zwar nicht so richtig doll, aber naja, der Aufwand ist schon dick genug, würde ich sagen. Man könnte zumindest für Linux das WatchDog-Skript, das eh von BIS kommt/kam, erweitern, um diesen Check abzuleisten. Ich glaube das wäre recht fix erledigt. Beim Windows... ja...da brauchste mindestens 'ne Powershell, oder irgendwas zum kompilieren und ausführen :trill: |
Oh primaa! Hat sich wieder jemand in die Hallen der Verzweiflung verirrt! Sei gegrüsst Poweruser *prost*
@Flicki: Die Traffic Frage hatte ich im BIF schoma gestellt: End of GameSpy - Page 2 - vllt. ists genau das, was du wissen möchtest. |
Ja sieht jetzt nicht dramatisch aus. Die Frage, auf welchen Layern eventueller Dauerbeschuss abgefangen wird, bleibt für mich noch offen. Ich bin da schon wieder etwas im Paranoiamodus. Wäre also interessant, wie sich die GS-Alternative vor bspw. DOSen schützt. Ich meine klar, im Moment geht's um OFP. Aber was ist denn, wenn der Poweruser hier die Bombe bastelt, auf die viiiiiiiiiiiiiiiiiiiele andere Spieler auch gewartet haben. Die Liste der eingestellten Spiele ist jedenfalls ellenlang. Damit würde dann auch die Relevanz als Angriffsziel, die Kosten durch Last im Netzwerk und im Tool selbst steigen.
Ich hab den Code jetzt nicht soweit durch, aber das wäre vielleicht noch als Punkt offen (oder eben nicht mehr :)). Wenn das klar ist und wir dürfen, dann würde ich glatt sagen, wir hosten das Ding :daumen: |
Für solche Fälle hab ich auch schon was eingebaut:
Im folgenden Text sind das keine Unterstreichungen, sondern Links zum Anklicken, die auf die jeweiligen Stellen im Quelltext verweisen. Das Lesen vom Netzwerkverkehr geschieht beim UDP Sockets asynchron in einem eigenen Thread. Der Hauptthread bedient sich dann an den Daten über das Consumer-Producer Modell: Einer produziert Daten, der andere arbeitet die ab. Beim TCP Socket werden die Verbindungen asynchron angenommen. Für den UDP Socket: In der Hauptschleife PowerServer:mainloop() lass ich nur 50 UDP Pakete pro Durchlauf abarbeiten. Die Hauptschleife läuft mit ~10 Iteratationen pro Sekunde (Wartezeit von 100ms nach jedem Durchlauf, wenn etwas mehr Last da ist halt nur 9 mal oder so). Damit kann schon mal der Server dortn nicht hängen, wenn mehr eingehende Daten da sind, als abgearbeitet werden können. Obendrauf wird, wenn in der Warteschlange der UDP Pakete mehr als 500 Stück sind (10 * das was pro Iterator abgearbeitet wird), die Warteschlange durchlaufen und die Pakete der jeweiligen Absender gezählt. Wenn nun ein Absender mit mehr als 10% aller wartenden Pakete dabei ist, bekommt dieser einen Tempban (von momentan noch 15 Minuten). Alle Pakete von diesem Absender in der Warteschlange werden dann nicht bearbeitet und alle neuen eingehenden von ihm verworfen. Außerdem werden eingehende Heartbeat Broadcasts nur von anderen Masterservern akzeptiert, wenn diese auch auf der Liste der Masterserver stehen. Für den Anfang behalte ich mir das Recht vor zu entscheiden, wer auf der Masterserverliste steht und wer nicht. Für den TCP Socket: Verbindungen bei denen 10 Sekunden lang nichts nennenswertes passiert, also die ihren internen Status nicht ändern, werden vom Server geschlossen. Wenn ein Client mehr als 5 gleichzeitige eingehende Verbingungen hat, bekommt dieser ebenfalls einen 15min Tempban (die Bans für UDP und TCP sind aber noch nicht gekoppelt, die laufen noch unabhängig von einander) Verbindungen bei denen mehr als 1 KiloByte an Daten im Empfangspuffer liegen, werden vom Server getrennt Die hier genannten Werte sind spontan ausgewählte Werte, die mir vernünftig schienen. Ich könnte aus denen eigentlich auch Einstellungen in der Konfig machen. Falls wer bessere Standardwerte hat, her damit. |
Liest sich für mich auch super. Würde ich via Konfig anbieten ja, damit jeder seine Thresholds wählen kann.
Dieses ominöse TCP-Connection-Limit auf bspw. Windows ist auch schon umgangen? Ich überlege auch was passiert, wenn der Queue gespammt wird und du jeweils 10sek Timeouts verbaust. Kanns damit irgendwie ein Szenario vom vollen, überlaufenden Queue geben, oder gar Bans aus Versehen? Vllt schicken die Server Requests im Intervall, was eventuell ein blockierter Queue als Angriff werten könnte? Wäre anstelle eines Bans, ein Packagedrop* nicht "freundlicher"? Oder man baut ne weiche und ne harte Grenze. Guckst Du wann die Pakete reinkommen, oder interessiert nur die Anzahl? *) Gibt 100 Pakete mit demselben Inhalt, ich streiche 99? Bei TCP bin ich noch nich so recht hintergestiegen, wie Du das machst. In der Anwendungsschicht bekommt man praktisch nur ein Command, ein Gamespy-Command. Sagen wir mal "\\\USCHI\\\QUERIET\\\DIE\\\WELT". Das muss ja nicht zwingend die Repräsentation im TCP-/UDP-Stack sein. Rein theoretisch könnten mehrere Pakete als Chunks das Command darstellen. Während die Anwendungsschicht eben nur das "GS-Command" als Ganzes begreift, hat die Transportschicht bspw. 2 TCP-Pakete vor Augen, wenn die von "GS-Command" spricht. Auf der Anwendungsschicht kann ich nun prüfen, wie oft mir Commands geschickt werden. Aber ich kann nicht prüfen, ob mich jemand mit Paketen spammt, weil diese Pakete eben in der Transportschicht sichtbar sind, aber nicht in der Anwendungsschicht. Das ist ja bei UDP vernachlässigbar, aber mit TCP kannste so jemanden blöde machen. Das ist vllt bei der Payloadmenge aber auch alles vernachlässigbar. Ich hoffe Du erkennst mein Problem beim Drübernachdenken :trill: Edit: Mir fällt noch die Frage ein, ob Du Queries selbst generierst (Scheduler) und die abfragenden Clients/Server damit mit semi-aktuellen, aber wenigstens nicht on-demand erzeugten Resultaten versorgst? Is ja auch nichts Anderes als zu verhindern, dass die Last durch Verarbeitung zur Weißglut getrieben wird. Nur hier halt wieder auf der Anwendungsschicht ^^ |
Zitat:
Zitat:
Oder meinst du, ich soll welche einbauen? Für was genau dann? Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zu Anwendungsschicht vs Transportschicht: Da die Anwendung keinen Zugriff auf die Transportschicht hat, sollte es auch nicht deren Aufgabe sein, das zu behandeln. Zitat:
|
Zitat:
Zitat:
Zitat:
Zitat:
Im Endeffekt würden ja so "schlaue" Tests reichen: Erst IP-Absenderadresse, stimmt die checkste auf Quellport, stimmt der auch dann checkste die Prüfsumme und erst dann die Daten. Also mit ner nativen C-Lib biste hier vermutlich deutlich schneller, ja. Aber weil es kein Echtzeitsystem ist, ist die Antwortzeit imho aber auch nen bissel vernachlässigbar. Die 2 Sekunden werden anfragende Systeme im Zweifelsfall sicher aushalten. Was ist denn, wenn man das Prozedere umdreht. Also sagt, der Queue sei sicher, indem man vor dem Hinzufügen in den Queue prüfen lässt, ob ein Hinzufügen überhaupt sinnig ist? Ich suche mir nur das letzte Pakete des Absenders im Queue und gucke wie das aussieht?! Gibt's gleich gar keins, super. Wenn Du natürlich eh periodisch rüberwatschelst um tote Verbindungen aufzuspüren, kannste das natürlich auch bleiben lassen - da könnte "erstemal alles aufn Queue und dann sortieren" schneller sein. Kannst du mit einem Javasocket überhaupt die Pakete prüfen? Ich meine NICHT die String-Commands! Wie läuft die Implementierung in den Gameservern? Schließen die nach einem Query die TCP-Verbindungen selbstständig, oder lassen die die irgendwie als "Long-Poll" ständig offen? Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Beispiel Fernsehprogramm: Da kann ich entweder immer einmal am Tag bei den Sendern anrufen, fragen, drucken und das Ergebnis als Kopie für alle ausliefern. Oder aber für jeden der mich fragt, jeweils direkt bei allen Sendern anrufen und fragen wie ihr Programm aussieht, und es dann on-demand drucken. Is halt einfach ne schöne Lastesenkung, wenns um den Output geht. Wie groß ist denn der Umfang an Daten, den die einzelnen Server an den Master schicken? Unterscheidet sich das von den Informationen, die jeder einzelne Gameserver über seinen eigenen Query-Port beantwortet? Edit: Ich hab mir das Protokoll nicht im Detail angeschaut, kann also sein, dass hier eh so gut wie alles vernachlässigbar ist :angel: |
Zitat:
Zitat:
Man könnte das evtl in einem anderen Thread machen lassen, den man dann ja ruhig voll auslasten kann, allerdings muss man dann für Threadsicherheit sorgen und mit diesen Synchronisierungen bremst man dann bestimmt den Hauptthread aus. Zitat:
Da gibts allerdings dann wieder ein Problem: Wenn sichs im Empfangspuffer vom Betriebssystem schon staut, dann sind die Empfangszeiten in der Anwendung nicht mehr zuverlässig. Also muss der Empfangsthread den Puffer dort schneller leeren, als er sich füllt. Zitat:
Zitat:
Das Senden von Heartbeats, Empfangen von Queries und Senden von Query-Antworten läuft alles über UDP hab. TCP kommt erst beim Masterserver ins Spiel, wenn die Clienten die Serverliste anfordern. Zitat:
Zitat:
Zitat:
Code:
\heartbeat\2303\gamename\opflashr\statechanged\1 Code:
\gamename\opflashr\gamever\1.96\groupid\261\hostname\server_name\hostport\2302\mapname\island_name\gametype\mission_name\numplayers\0\maxplayers\20\gamemode\openplaying\timeleft\15\param1\0\param2\0\actver\196\reqver\196\mod\RES\equalModRequired\0\password\0\gstate\2\impl\sockets\platform\win\final\\queryid\2.1 Zitat:
|
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Alles sehr spannend. Aktuell fällt mir nix mehr ein, was man noch beachten könnte/müsste. Macht'n guten Eindruck :daumen: |
Zitat:
Zitat:
Ansonsten hat der GameSpy Masterserver das halt immer gemacht, um bei den Serverinformationen auf dem aktuellen Stand, denn bei dem kann man beim Abrufen der Serverliste auch einen Filter mit angeben. Dass man zB nur die IPs der Server IPs bekommt, auf denen mind. 3 Spieler sind. Zitat:
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:21 Uhr. |
Angetrieben durch vBulletin, Entwicklung von Philipp Dörner & Tobias