Zitat von
flickflack
Ich meinte damit, dass jemand UDP-Floods schicken könnte. Bevor der Queue abgearbeitet wird, könnte er schon wieder voll sein. Oder ist das völlig ausgeschlossen?
Das ist nicht ausgeschlossen. Das wird sehr wahrscheinlich eintreten, bis der Spamer auf der Banliste steht und der Hauptthread aufgeholt hat.
Zitat:
Vllt gibts ja ein Trigger der merkt, dass der Queue vollläuft und ihn dann zwanghaft abarbeitet. Also neben dem zeitlichen Intervall.
Den Trigger gibts, momentan lass ich, nachdem der Hauptthread dran war, prüfen, ob in der Queue noch was drinnen ist und wenn ja, wieviel. Ein zwanghaftes Abarbeiten wollte ich im Hauptthread unbedingt vermeiden, da man den Server damit zwingen könnte sich nur um UDP Pakete zu kümmern, was einem DoS für die TCP Verbindungen gleich kommt.
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:
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?
Die Idee gefällt mir, vorallem würde man damit die Last vom Hauptthread auf den Empfängerthread verlagern, der eh noch nicht viel zu tun hat, außer zu empfangen und Bans zu prüfen. Ich bin aber immer noch dagegen sich den Inhalt der Pakete bei Überlastung anzuschauen. Viel mehr kann man hier, wenn man sich den Zeitpunkt des letzten Pakets merkt, recht einfach eine Empfangs-Geschwindigkeitsbegrenzung bauen. zB: Wer x Mal schneller als y Pakete/s gesendet hat, kommt auf die TempBanliste.
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:
Kannst du mit einem Javasocket überhaupt die Pakete prüfen?
Nein, an die TCP Pakete in der Transportschicht kommt man nicht ran, da hat man nur Zugriff auf den Datenstrom. Bei UDP sollten die Pakete, die der Javasocket liefert, mit den anderen übereinstimmen, es sei denn die waren zu groß und mussten fragmentiert werden.
Zitat:
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?
Die Gameserver haben keine TCP Verbindungen, nur UDP (OFP zumindest, bei anderen Spielen: kA).
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:
Ja also macht der TCP-Socket, so wie ich vermutet habe, jeweils ne Verbindung auf? Und Du prüfst bei den registrierten nur periodisch, ob was im Stream steht und schließt die dann ggf.
Richtig
Zitat:
Ich glaub ich mein was Anderes, vor allem im Output. Wenn eine Instanz den Status aller Server oder eines Servers abfragen will, dann erzeugt das ja Last, weil die GS-Alternative rödeln muss, um an Infos zu kommen.
Hier läuft das etwas anders ab. Wenn ein Client die Serverliste abfordert, dann bekommt er nur die IPs der Server, die sich bis dahin erfolgreich beim Masterserver registiert haben und momentan in der Serverliste stehen. Dabei findet kein Datenaustausch mit den Spielservern statt. Wenn ein Client den Status eines Spielservers erfahren möchte, dann soll er eine Query an den Spielserver schicken und nicht an den Masterserver. Der Masterserver unterstützt in dem Sinne auch gar keine eingehenden UDP Queries.
Zitat:
Wie groß ist denn der Umfang an Daten, den die einzelnen Server an den Master schicken?
Bei jedem Statuswechsel (Erstellen, Warten, Mission laden, Besprechung, Spielen, Nachbesprechung) wird ein Heartbeat an den Masterserver geschickt:
Code:
\heartbeat\2303\gamename\opflashr\statechanged\1
Daraufhin sendet der Masterserver eine Query zurück und bekommt als Antwort eine etwas größere Nachricht, die etwa so ausschaut:
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:
Unterscheidet sich das von den Informationen, die jeder einzelne Gameserver über seinen eigenen Query-Port beantwortet?
Nein, das ist extakt die selbe Prozedur, mit der zB OFPMonitor die Informationen von den Spielservern abfragt. Außer, dass es für den Masterserver mehr oder weniger unnötig ist die Spielerinformationen abzufragen, weil er die nicht wirklich braucht.