HX3 Foren  

  HX3 Foren > Games > Operation Flashpoint > Community

Community Die Gerüchteküche brodelt ...

Antwort
 
Themen-Optionen Ansicht
Alt 31.03.2014, 14:25   #1 (permalink)
10 Jahre hx3
5000 Beiträge10.000 Beiträge15.000 Beiträge
 
Benutzerbild von burns
 
Registriert seit: 13.04.2003
Ort: Monerica
Alter: 41
Beiträge: 32.968
Standard OFP Serverliste

End of Gamespy
Zitat:

End of Gamespy

Important notice: effective May 31, 2014, Gamespy will cease providing all hosted services for all games.

This is going to affect multiplayer in our games that use Gamespy for matchmaking, cd keys authentification and NAT traversal from Arma: Resistance to Arma 3. We are planning to introduce an alternative solution using Steam to Arma 2: Operation Arrowhead and Arma 3 users.

Other games (Take On Helicopters, Arma 2, Arma 2: Free, Arma, Arma: Cold War Assault) will have more limited multiplayer experience with loss of server browser, cd key authentification and NAT traversal systems. That said, direct IP connection to servers should work even after Gamespy services are no longer available.

We apologize for any inconvenience.




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!


__________________

burns ist offline   Mit Zitat antworten
Alt 01.04.2014, 11:24   #2 (permalink)
10 Jahre hx3
500 Beiträge
 
Benutzerbild von Atsche
 
Registriert seit: 06.07.2003
Beiträge: 600
Standard

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.
Atsche ist offline   Mit Zitat antworten
Alt 01.04.2014, 14:42   #3 (permalink)
10 Jahre hx3
5000 Beiträge10.000 Beiträge15.000 Beiträge
 
Benutzerbild von burns
 
Registriert seit: 13.04.2003
Ort: Monerica
Alter: 41
Beiträge: 32.968
Standard

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
__________________

burns ist offline   Mit Zitat antworten
Alt 01.04.2014, 14:58   #4 (permalink)
His Awesomeness!
10 Jahre hx3
5000 Beiträge
 
Benutzerbild von flickflack
 
Registriert seit: 25.07.2006
Ort: Regnum Borussiae
Beiträge: 9.282
Standard

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
flickflack ist offline   Mit Zitat antworten
Alt 06.04.2014, 19:40   #5 (permalink)
10 Jahre hx3
5000 Beiträge10.000 Beiträge15.000 Beiträge
 
Benutzerbild von burns
 
Registriert seit: 13.04.2003
Ort: Monerica
Alter: 41
Beiträge: 32.968
Standard

Zitat von qbt

I have already programmed a prototype alternative master server for Operation Flashpoint: Resistance / ArmA: Cold War Assault. More details to follow in the upcoming days.

http://forums.bistudio.com/showthrea...=1#post2660315



Es geht weiter
__________________

burns ist offline   Mit Zitat antworten
Alt 07.04.2014, 08:14   #6 (permalink)
His Awesomeness!
10 Jahre hx3
5000 Beiträge
 
Benutzerbild von flickflack
 
Registriert seit: 25.07.2006
Ort: Regnum Borussiae
Beiträge: 9.282
Standard

Geht's komischerweise auch iwi so. Ich konnte gestern Abend in OFP und A2/OA noch alles querien. Jedenfalls den letzten Stand
flickflack ist offline   Mit Zitat antworten
Alt 07.04.2014, 08:23   #7 (permalink)
10 Jahre hx3
500 Beiträge1000 Beiträge2.500 Beiträge
 
Benutzerbild von MrCharles
 
Registriert seit: 22.12.2008
Beiträge: 3.641
Standard

Flicki, wird erst am 31. Mai abgeschaltet.
MrCharles ist offline   Mit Zitat antworten
Alt 07.04.2014, 09:08   #8 (permalink)
His Awesomeness!
10 Jahre hx3
5000 Beiträge
 
Benutzerbild von flickflack
 
Registriert seit: 25.07.2006
Ort: Regnum Borussiae
Beiträge: 9.282
Standard

Dachte Ende März? Dann hat ja BI noch ausreichend Zeit LOL.
flickflack ist offline   Mit Zitat antworten
Alt 17.05.2014, 09:29   #9 (permalink)
50 Beiträge
 
Registriert seit: 28.10.2006
Beiträge: 99
Standard

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)

Mir fehlen leider die technischen Möglichkeiten.
rambazamba ist offline   Mit Zitat antworten
Alt 27.05.2014, 15:21   #10 (permalink)
Newbie
 
Registriert seit: 27.05.2014
Beiträge: 16
Poweruser eine Nachricht über ICQ schicken Poweruser eine Nachricht über MSN schicken
Standard

Zitat von flickflack Beitrag anzeigen

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.

Genau damit beschäftige ich mich seit etwas über einem Monat und hab dabei einen Masterserver für ofp/cwa geschrieben. Mein Projekt ist hier einsehbar: https://github.com/Poweruser/PowerServer

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?

Geändert von Poweruser (27.05.2014 um 15:22 Uhr). Grund: Link eingefügt
Poweruser ist offline   Mit Zitat antworten
Alt 27.05.2014, 16:20   #11 (permalink)
His Awesomeness!
10 Jahre hx3
5000 Beiträge
 
Benutzerbild von flickflack
 
Registriert seit: 25.07.2006
Ort: Regnum Borussiae
Beiträge: 9.282
Standard

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:

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.

Das mit den IPs ist doof ja, falls man nix festes zum Hosten findet. Ich meine für den Rest der Welt zu hosten, auch wenns nur noch 20 Server sind, ist vllt doch etwas teuer. Konntest Du eventuell mal schauen, wieviel Traffic eine Box und nur seine Heartbeats aufm Master so anrichten?

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
flickflack ist offline   Mit Zitat antworten
Alt 27.05.2014, 16:31   #12 (permalink)
10 Jahre hx3
5000 Beiträge10.000 Beiträge15.000 Beiträge
 
Benutzerbild von burns
 
Registriert seit: 13.04.2003
Ort: Monerica
Alter: 41
Beiträge: 32.968
Standard

Oh primaa! Hat sich wieder jemand in die Hallen der Verzweiflung verirrt! Sei gegrüsst Poweruser




@Flicki: Die Traffic Frage hatte ich im BIF schoma gestellt: End of GameSpy - Page 2 - vllt. ists genau das, was du wissen möchtest.
__________________

burns ist offline   Mit Zitat antworten
Alt 27.05.2014, 16:41   #13 (permalink)
His Awesomeness!
10 Jahre hx3
5000 Beiträge
 
Benutzerbild von flickflack
 
Registriert seit: 25.07.2006
Ort: Regnum Borussiae
Beiträge: 9.282
Standard

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
flickflack ist offline   Mit Zitat antworten
Alt 27.05.2014, 20:19   #14 (permalink)
Newbie
 
Registriert seit: 27.05.2014
Beiträge: 16
Poweruser eine Nachricht über ICQ schicken Poweruser eine Nachricht über MSN schicken
Standard

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.

Geändert von Poweruser (27.05.2014 um 20:53 Uhr).
Poweruser ist offline   Mit Zitat antworten
Alt 28.05.2014, 09:20   #15 (permalink)
His Awesomeness!
10 Jahre hx3
5000 Beiträge
 
Benutzerbild von flickflack
 
Registriert seit: 25.07.2006
Ort: Regnum Borussiae
Beiträge: 9.282
Standard

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

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 ^^
flickflack ist offline   Mit Zitat antworten
Alt 28.05.2014, 23:47   #16 (permalink)
Newbie
 
Registriert seit: 27.05.2014
Beiträge: 16
Poweruser eine Nachricht über ICQ schicken Poweruser eine Nachricht über MSN schicken
Standard

Zitat:

Dieses ominöse TCP-Connection-Limit auf bspw. Windows ist auch schon umgangen?

Ich weiß nicht, was genau du damit meinst. Das hier vielleicht?: MSDN: Avoiding TCP/IP Port Exhaustion

Zitat:

Ich überlege auch was passiert, wenn der Queue gespammt wird und du jeweils 10sek Timeouts verbaust.

Beim UDP Code ist die einzige blockierende Methode mit 10s Timeout die receive(..) im UDPReceiverThread. Die Klasse hat aber ihren eigenen Thread. Der Hauptthread führt dort keine blockierenden Methoden aus.
Oder meinst du, ich soll welche einbauen? Für was genau dann?

Zitat:

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?

Dafür gibts die prozentuale Marke (momentan 10%). Wenn in dem Fall ein legitimer Server, der gerade viele Heartbeats schickt, darüberhinaus kommt, dann könnte das schon passieren. Allerdings muss er da schon sehr viel mehr als im üblichen Betrieb schicken

Zitat:

Wäre anstelle eines Bans, ein Packagedrop* nicht "freundlicher"?

Nur für die legitimen Server. Wobei das in dem Fall, mit dermaßen vielen Paketen kein geringer Aufwand ist, da jedes Paket zu parsen und zu vergleichen, wenn die Warteschlange so überfüllt ist. Da sollte dann egal sein, was man empfängt, bis die Anzahl wieder reduziert ist. Damit würde man dem Angreifer sogar noch entgegenkommen, weil man für die Dauer seines Angriffs selber noch für eine höhere CPU Last sorgt.

Zitat:

Oder man baut ne weiche und ne harte Grenze.

Lohnt sich der Aufwand? Ich hab ne bessere Idee, die Bandauer ergibt sich aus dem Verhältnis: Pakete des Senders / Warteschlange

Zitat:

Guckst Du wann die Pakete reinkommen, oder interessiert nur die Anzahl?

Nur die Anzahl

Zitat:

Bei TCP bin ich noch nich so recht hintergestiegen, wie Du das machst.

Damit der Hauptthread bei den TCP Verbindungen keine blockierenden Methoden aufrufen muss, und auch nicht für jede Verbindung einen eigenen Thread zu haben, besucht der Hauptthread jede Verbindung einmal pro Hauptschleifeniteration und prüft, ob neue Daten empfangen wurden. Dann werden die Daten im Puffer geparst und geschaut ob die vollständig und gültig sind. Die QueryConnections durchlaufen dabei verschiedene Zustände. In jedem Zustand müssen andere Bedingungen erfüllt sein, um in den nächsten zu kommen. Sind einmal die Bedingungen innerhalb von 10 Sekunden seit dem letzten Zustandswechsel nicht erfüllt, wird die Verbindung getrennt.


Zu Anwendungsschicht vs Transportschicht:
Da die Anwendung keinen Zugriff auf die Transportschicht hat, sollte es auch nicht deren Aufgabe sein, das zu behandeln.

Zitat:

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 ^^

Bei jedem Heartbeat geht gleich danach ein "\status\" Query raus an den Spielserver, damit der Masterserver den aktuellen Spielzustand kennt. Das ist im Moment eigentlich nur beim ersten Heartbeat nötig, um an so Informationen wie den Spielport, den Servernamen und die Spielversion zu kommen. Ansonsten könnte man die danach auch weglassen. Falls aber jemand später mal ein Serverprotokoll mitloggen will, um sowas wie Operation Flashpoint Game Statistics - Index zu bauen, dann sind die wieder notwendig. Den Clienten, die die Serverliste abfragen, werden nur die ServerIPs zusammen mit dem Spielport geschickt. Diese Infos liegen nach dem ersten Heartbeat-Statusquery austausch vor.

Geändert von Poweruser (28.05.2014 um 23:56 Uhr).
Poweruser ist offline   Mit Zitat antworten
Alt 29.05.2014, 08:57   #17 (permalink)
His Awesomeness!
10 Jahre hx3
5000 Beiträge
 
Benutzerbild von flickflack
 
Registriert seit: 25.07.2006
Ort: Regnum Borussiae
Beiträge: 9.282
Standard

Zitat:

Ich weiß nicht, was genau du damit meinst. Das hier vielleicht?: MSDN: Avoiding TCP/IP Port Exhaustion

Ne ich meinte das Problem mit den 10 TCP-Connections, die mal gleichzeitig geöffnet werden konnten. Da gab's doch das Problem, dass mit nem normalen Windows bzw. den Servern ohne Konfiguration nur ne limiterte Anzahl von Verbindungen aufbauen kannst. Ich glaube das wurde mit XP gegen diesen einen Glitch, mit irgendeinem ServicePack, eingeführt. Hab gerade nochmal gelesen, betrifft wohl nur clients.

Zitat:

Beim UDP Code ist die einzige blockierende Methode mit 10s Timeout die receive(..) im UDPReceiverThread. Die Klasse hat aber ihren eigenen Thread. Der Hauptthread führt dort keine blockierenden Methoden aus.
Oder meinst du, ich soll welche einbauen? Für was genau dann?

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? Vllt gibts ja ein Trigger der merkt, dass der Queue vollläuft und ihn dann zwanghaft abarbeitet. Also neben dem zeitlichen Intervall.

Zitat:

Dafür gibts die prozentuale Marke (momentan 10%). Wenn in dem Fall ein legitimer Server, der gerade viele Heartbeats schickt, darüberhinaus kommt, dann könnte das schon passieren. Allerdings muss er da schon sehr viel mehr als im üblichen Betrieb schicken

Joar oki.

Zitat:

Nur für die legitimen Server. Wobei das in dem Fall, mit dermaßen vielen Paketen kein geringer Aufwand ist, da jedes Paket zu parsen und zu vergleichen, wenn die Warteschlange so überfüllt ist. Da sollte dann egal sein, was man empfängt, bis die Anzahl wieder reduziert ist. Damit würde man dem Angreifer sogar noch entgegenkommen, weil man für die Dauer seines Angriffs selber noch für eine höhere CPU Last sorgt.

Klar, ist ein bissel aufwendig, aber macht ne DPI einer FW auch nicht anders, und nebenbei kannste sogar noch daddeln.

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:

Lohnt sich der Aufwand? Ich hab ne bessere Idee, die Bandauer ergibt sich aus dem Verhältnis: Pakete des Senders / Warteschlange

Jop. In der Tat besser.

Zitat:

Nur die Anzahl

Ja hier meinte ich, dass ja nen Queue theoretisch volllaufen könnte (mal selbst im unwahrscheinlichsten Fall) und dann ggf. Falschmeldungen absondern würde, weil im Queue mittlerweile 100 Pakete vom selben Server stehen, obwohl dazwischen vllt immer 3 Minuten liegen. Daher find ich ne weiche Landung hier immer netter. Aber jut.

Zitat:

Damit der Hauptthread bei den TCP Verbindungen keine blockierenden Methoden aufrufen muss, und auch nicht für jede Verbindung einen eigenen Thread zu haben, besucht der Hauptthread jede Verbindung einmal pro Hauptschleifeniteration und prüft, ob neue Daten empfangen wurden. Dann werden die Daten im Puffer geparst und geschaut ob die vollständig und gültig sind. Die QueryConnections durchlaufen dabei verschiedene Zustände. In jedem Zustand müssen andere Bedingungen erfüllt sein, um in den nächsten zu kommen. Sind einmal die Bedingungen innerhalb von 10 Sekunden seit dem letzten Zustandswechsel nicht erfüllt, wird die Verbindung getrennt.

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.

Zitat:

Zu Anwendungsschicht vs Transportschicht:
Da die Anwendung keinen Zugriff auf die Transportschicht hat, sollte es auch nicht deren Aufgabe sein, das zu behandeln.

Und hier sehe ich eben ein Problem im Gesamtpaket, nicht direkt in der Anwendung: Du kannst also nur auf Anwendungsschicht absichern, dass niemand Mist baut. Da könnte man aber einen Tick zu spät sein, wenn man nicht auch noch Hilfen zur FW-Konfiguration mit anbieten möchte. Ich sag's nur. Ist immerhin kein zu unterschätzendes Problem. Muss man dann vielleicht einfach nur dazu schreiben. Mit ner ordentlichen Konfiguration an der lokalen Firewall, reduzieren sich irgendwie auch gleich automatisch viele andere Probleme. Ich glaube doppelte Pakete, und vor allem Spam, erkennt sonen Teil recht flott.

Zitat:

Bei jedem Heartbeat geht gleich danach ein "\status\" Query raus an den Spielserver, damit der Masterserver den aktuellen Spielzustand kennt. Das ist im Moment eigentlich nur beim ersten Heartbeat nötig, um an so Informationen wie den Spielport, den Servernamen und die Spielversion zu kommen. Ansonsten könnte man die danach auch weglassen. Falls aber jemand später mal ein Serverprotokoll mitloggen will, um sowas wie Operation Flashpoint Game Statistics - Index zu bauen, dann sind die wieder notwendig. Den Clienten, die die Serverliste abfragen, werden nur die ServerIPs zusammen mit dem Spielport geschickt. Diese Infos liegen nach dem ersten Heartbeat-Statusquery austausch vor.

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.

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
flickflack ist offline   Mit Zitat antworten
Alt 29.05.2014, 20:10   #18 (permalink)
Newbie
 
Registriert seit: 27.05.2014
Beiträge: 16
Poweruser eine Nachricht über ICQ schicken Poweruser eine Nachricht über MSN schicken
Standard

Zitat von flickflack Beitrag anzeigen

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.

Geändert von Poweruser (29.05.2014 um 20:12 Uhr).
Poweruser ist offline   Mit Zitat antworten
Alt 30.05.2014, 09:34   #19 (permalink)
His Awesomeness!
10 Jahre hx3
5000 Beiträge
 
Benutzerbild von flickflack
 
Registriert seit: 25.07.2006
Ort: Regnum Borussiae
Beiträge: 9.282
Standard

Zitat von Poweruser Beitrag anzeigen

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.

Yep. Niemand mag Thread-Synchronisation. Kann ich voll nachvollziehen ^^

Zitat von Poweruser Beitrag anzeigen

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.

Ja, klar. Kommt halt auch immer auf das Protokoll an. Wenn sich das alles auch ohne DPI realisieren lässt, dann soll's so sein. Ich setze mir dann aber lokal trotzdem ne FW auf, die ne DPI macht ^^

Zitat von Poweruser Beitrag anzeigen

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.

Ja okay, hab ich mir fast gedacht.

Zitat von Poweruser Beitrag anzeigen

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.

Die Kommunikation zwischen Gameserver und Masterserver ist also lediglich UDP, und nur Gameclient und Masterserver kommunizieren via TCP? Okay, verstanden.


Zitat von Poweruser Beitrag anzeigen

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.

Juti, der Austauch von ein paar IPs ist sicher vernachlässigenswert. Ich bin trotzdem immer ein Freund davon, hier am Beispiel IP-Liste, die abzufragenden Daten im Vorfeld zu erstellen und nicht on-demand. Selbst das Durchforsten von Datenstrukturen kostet. Je nachdem wie hochfrequent und wie aktuell man sein möchte, bietet sich das eben an. Damit gibts nur eine Instanz die Last verursacht, nämlich der Scheduler. Jeder der fragt bekommt nur ne Auslieferung, ohne zuvor angeschlossene Abfrage. Aber wie gesagt, wenn Du das nicht für nötig hälst, ist das ja auch vollkommen in Ordnung. Du hast Dir da offensichtlich selbst genug nen Kopp gemacht.


Zitat von Poweruser Beitrag anzeigen

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
Ah, der Statuswechsel sorgt also immer wieder für einen neuen "Handshake" mit dem Master, inklusive Statusaustausch. Verstehe. Der Heartbeat kommt nicht periodisch, sondern ist an Events gebunden? Bei denen sitzt bestimmt nen Observer auf dem Eventsourcing/Queue und guckt sich die Heartbeats an.Gar nicht mal soooooo doof von GS, warum geben die auf?

Zitat von Poweruser Beitrag anzeigen

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.

Okay, aber er könnte die Infos pro Gameserver rausgeben? Vllt macht man hier noch eine Unterscheidung zum GS-Master und definiert gleich: Nö, ich gebe wirklich nur IPs zum Spiel. Den Rest kann die Implementierung machen.


Alles sehr spannend. Aktuell fällt mir nix mehr ein, was man noch beachten könnte/müsste. Macht'n guten Eindruck
flickflack ist offline   Mit Zitat antworten
Alt 30.05.2014, 15:41   #20 (permalink)
Newbie
 
Registriert seit: 27.05.2014
Beiträge: 16
Poweruser eine Nachricht über ICQ schicken Poweruser eine Nachricht über MSN schicken
Standard

Zitat:

Juti, der Austauch von ein paar IPs ist sicher vernachlässigenswert. Ich bin trotzdem immer ein Freund davon, hier am Beispiel IP-Liste, die abzufragenden Daten im Vorfeld zu erstellen und nicht on-demand. Selbst das Durchforsten von Datenstrukturen kostet. Je nachdem wie hochfrequent und wie aktuell man sein möchte, bietet sich das eben an.

Das lässt sich einrichten. Bei ner recht langen Serverliste würde sich das schon lohnen, wenn häufiger die Liste abgerufen wird, als sich Server anmelden und wegen Meldetimeout aus der Liste fliegen.


Zitat:

Ah, der Statuswechsel sorgt also immer wieder für einen neuen "Handshake" mit dem Master, inklusive Statusaustausch.

Beim ersten Heartbeat ists Pflicht, um 1) sicherzustellen, dass der Server von außen erreichbar ist 2) an wichtige Daten zu kommen, wie Spielport und Servername.
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:

Okay, aber er könnte die Infos pro Gameserver rausgeben? Vllt macht man hier noch eine Unterscheidung zum GS-Master und definiert gleich: Nö, ich gebe wirklich nur IPs zum Spiel. Den Rest kann die Implementierung machen.

Um den nachzuahmen hab ich das mal auch eingebaut, wenn die Info aber keiner braucht und statt dessen Bandbreite gespart werden soll, dann kann das auch wieder raus, oder als Einstellung in die Konfig.


Zitat:

Der Heartbeat kommt nicht periodisch, sondern ist an Events gebunden?

Beides, spätestens 5 Minuten nach dem letzten Heartbeat kommt ein periodischer
Poweruser ist offline   Mit Zitat antworten
Antwort


Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1)
 
Themen-Optionen
Ansicht

Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Stammtisch Webinstaller Rockhount Multiplayer 106 07.01.2014 15:09


Kontakt - HX3.de - Archiv - Nach oben

Angetrieben durch vBulletin, Entwicklung von Philipp Dörner & Tobias



SEO by vBSEO 3.2.0 ©2008, Crawlability, Inc.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119