spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »simbad«

Dann gibt es eben keinen XBox support. Es ist und bleibt eine Frage der Anforderungen. Es muss definiert sein, zwischen welchen Plattformen kommuniziert werden soll. Diese Festlegung macht man entweder explizit indem man dies niederschreibt, oder implizit durch die Art der Realisierung, wobei das nicht der reinen Lehre vom Requirement-Engineering entsprechen würde.

Ich glaube ich "brauch" diese Anforderung ganz einfach nicht in meinem Framework Das fällt dann unter die gleiche Rubrik wie mein "Events besitzen nur Primitivdaten": Limitations.

Mal was anderes: Threading.

Meine Server- und Client-Klassen verwenden mehrere Threads. Derzeit folgende:

• Server: accept (eingehende Verbindung annehmen, IP-Ban prüfen, neuen Worker erstellen und hinzufügen)
  
• pro Worker: send (für diesen Worker die ausgehenden Events versenden)
  
• pro Worker: recv (für diesen Worker die eingehenden Daten in Events umwandeln)
  

• pro Client: send (für diesen Client die ausgehenden Events versenden)
  
• pro Client: recv (für diesen Client die eingehenden Daten in Events umwandeln)
  

Sind das zu viele Threads? Sollte ich z.B. send und recv jeweils zusammenfassen (d.h. pro Worker einen Thread, und auf dem Client nur einen statt zwei)? Oder ist das so vielleicht sogar sinnvoller? Die Idee dahinter war, dass ich kein weiteres Management implementieren muss (d.h. nach wie vielen versandten Events wieder geguckt wird, ob welche ankommen) ... wobei: das könnte man vielleicht auch im Wechsel machen. Nur: wo baue ich dann den Delay ein, dass meine CPU-Auslastung nicht sinnlos nach oben schnellt, wenn gar nichts gemacht wird? Bisher wird gesendet, bis kein ausgehendes Event mehr vorhanden ist und dann kurz gewartet (und anschließend weitergesendet). Das Empfangen läuft genauso: empfangen bis auf dem Socket keine Aktivität mehr ist, dann kurz warten und weiter Empfangen / bzw. gucken, ob nun Aktivität ist.

Ich hoffe ihr wisst was ich meine

LG Glocke

Zitat von »BlueCobold«

Völlig unnötig, weil es auch mit 2-3 geht (1 receive, 1-2 send dürfte ausreichen). Mehr als 10 würde ich persönlich niemals empfehlen. Bei unserem MMORPG-Server mit 2000 aktiven Spielern waren eine Hand voll Threads für die Kommunikation ausreichend. Für die Bearbeitung der Daten und der Logik hatten wir aber einen Threadpool. Wie viel da drin waren, weiß ich nicht mehr, aber da wir 16 Kerne hatten, waren's vermutlich 10-14.

Also auf dem Server generell 3 Threads? Würdest du den accepter Thread da mit in den Receive-Thread reinsetzen?

Ich könnte mir das folgendermaßen vorstellen (1 recv, 1 send):

Receive


Send


Würdest du das auf dem Client dann zusammenfassen zu einem Send/Recv-Loop? Die Sache mit dem Thread-Pool auf dem Server klingt sehr sinnvoll

LG Glocke

/EDIT:

Zitat von »simbad«

Du kannst auf die sockets warten.
Unter Linux mit select, poll oder epoll. Und Windows mit WaitForMultipleEvent und sicherlich auch mit einer fortschrittlicheren Methode.
Fürs Senden kannst du eine queue nehmen. Da wartet der Sende-Thread drauf. Immer wenn jemand was zum senden in die Queue stellt wird ein event ausgelöst. Der Thread wartet auf dieses Queue event, versucht dann alles zu verschicken, was in der queue steht. Das senden würde ich eventuell non-blocking machen. Wenn die Socket aus welchen Gründen auch immer keine Daten mehr zum senden entgegen nehmen kann gibts einen Fehlerocde. WOULDBLOCK oder so ähnlich.
Wenn die Socket wieder daten senden kann, gibt es ein entsprechendes Event das anzeigt das es weitergeht.
Diese Information, das du Datensenden kannst ist beim aufbau der Verbindung abzuwarten. Nach erfolgreichem Connect muss erst abgewartet werden, bis das Write-Event kommt. Ansonsten passiert da nix.

Naja ich verwende absichtlich nicht-blockierendes Lesen vom Socket (indem ich vorher auf Aktivität prüfe; SDL_net bietet da ein paar Funktionen). Was die queues angeht: schau dir mal meine Lösung auf GitHub an Das geht schon in die Richtung

Also ca. so beim Client?



Wenn am Client zu viele Events erzeugt werden, verzögert sich das Lesen neuer Events. Aber ich glaube das sollte verkraftbar sein.

LG Glocke

Zitat von »BlueCobold«

Ein select() ist hier sicherlich die bessere Lösung als non-blocking Polling.

Was meint ihr eigentlich genau mit select()? Ich setze auf SDL_net auf und da habe ich SDLNet_TCP_Recv zum lesen und SDLNet_CheckSockets sowie SDLNet_SocketReady zum Prüfen auf Aktivität.

Zitat von »simbad«

SDLNet_CheckSockets

ist dürfte auf select o.ä aufbauen. Du wartest da einfach ewig. Wenn die Funktion zurückkehrt ist was passiert.

Naja sie bekommt ein SocketSet und einen Timeout. Nach dem Timeout gibt sie an, ob Aktivität auf dem Socket ist oder nicht. Will ich Lesen und dabei warten bis Daten da sind, verwende ich direkt SDLNet_TCP_Recv; lagere ich die Überprüfung vor, lese ich schließlich auch mit der Funktion, nur blockiert zwingend sie nicht weil ja prinzipiell Aktivität vorliegt.

Zitat von »dot«

Um was für eine Art Spiel geht es und wieviele Clients soll der Server unterstützen?

Ich will das Framework für ein Multiplayer-RPG (nicht MMORPG, eher Diablo-artig vom Netzwerk-Umfang her; also Clients im niedrigen zweistelligen Bereich) verwenden. Da sollte der obige Threading-Ansatz eigentlich vollkommen ausreichen, oder?