spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »BlueCobold«

Nein. Die Funktion wartet, bis etwas auf dem Socket ankommt oder bis der Timeout erreicht ist, je nachdem, was früher eintritt.

	Quellcode
1 2 3 4 5 6 7 8	solange server online: wenn aktivität auf listener socket: nimm neuen client an für jeden worker socket: solange aktivität: lies event gib event an in-queue delay

	Quellcode
1 2 3 4 5 6 7	solange server online: nimm event von out-queue solange event leer: delay nimm event von out-queue ermittle ziel des events (worker) sende event an worker

	Quellcode
1 2 3 4 5 6 7 8 9 10 11 12	solange client online // senden bis nichts mehr zu senden solange trve: nimm event von out-queue wenn event leer: break sende event an server // empfangen bis nichts mehr zu empfangen solange aktivität auf socket: empfange event gib event an in-queue delay

Zitat von »BlueCobold«

1) Wieso sollte der Accept-Thread irgendwas anderes machen als Accept? Receive-Thread für Server über select() oder das SDL-Äquivalent.

Zitat von »BlueCobold«

2) Server Send-Thread sieht ok aus - außer vielleicht Nagle-Ack.

Zitat von »BlueCobold«

3) Client Send/Receive-Thread ist nicht gut. Blockiert sich gegenseitig. Receive und Send sollten unabhängig voneinander sein. Nicht pro Client einen Thread, sondern einen pro Aufgabe (Aufgabe = Send ODER Receive).

Zitat von »BlueCobold«

Ich wiederhole: Ein Accept gehört meiner Meinung nach nicht in einen Receive-Loop, denn Receive selbst sollte wie select() arbeiten, die entsprechende SDL-Funktion wurde Dir ja schon genannt. Wenn man das aber so macht, müsste ein neuer Client so lange warten, bis ein anderer Daten schickt. Nicht mit einer Funktion wie select() zu arbeiten heißt Pollen, weil select() blockt und das sogar auf eine sehr sinnvolle Art und Weise. Polling ist nie gut aus diversen Gründen.

Zitat von »BlueCobold«

Delayed Ack und Nagle-Algorithm. Findet sich im Netz, kann ziemlichen Ärger bauen.

Zitat von »simbad«

Ein listener erzeugt, wenn ich nicht ganz falsch liege ein Read-Event wenn eine neue Verbindung reinkommt.

Zitat von »dot«

Ich würde mir eher erstmal die Frage stellen, was der Server mit den empfangenen Daten eigentlich anstellen wird. Nehmen wir an, dass Senden und Empfangen gelöste Probleme sind, wie genau werden die Daten am Server verarbeitet?

• Daten werden in JSON-Objekten gesammelt und können serialisiert / deserialisiert werden. Die gängigen Container können in JSON-Objekte abgebildet werden.
  
• Einige Speicherlecks beim Werfen von Exceptions wurden behoben. (aber sichtlich noch nicht alle!)
  
• Beim Lesen der JSON-Objekte wird nicht mehr mit malloc und void-Pointern gearbeitet. Statt dessen wird auf das Mittel der Deserialisierung zurückgegriffen und ein neues JSON-Objekt erstellt, das mittels delete gelöscht werden kann. Dadurch wurden einige Speicherlecks behoben.
  
• Probleme aufgrund verschiedener Größen von Datentypen wurden durch (die von C++11 gegebenen) Datentypen mit fester Länge (z.B. std::uint32_t - siehe http://en.cppreference.com/w/cpp/types/integer) eingedämmt. Soweit ich es überblicke, habe ich bereits das ganze Framework auf diese Typen umgebaut - oder fast das ganze
  
• Weitere plattformspezifische Probleme wurden durch die Serialisierung / Deserialisierung verringert. Mir ist derzeit erstmal kein weiteres Problem bewusst - ich bin aber offen für neue Probleme
  
• Komprimierung ist bisher noch nicht eingebaut. Da aktuell aber serialisierte JSON-Objekte als Zeichenkette versandt werden, erscheint ein nachträgliches Implementieren einer Komprimierung bzw. Dekomprimierung recht einfach.
  
• Bislang wird ausschließlich die Client-Server-Architektur unterstützt. Wenn jemand Interesse an einer Peer-to-Peer-Implementierung hat, kann ich da ggf. etwas bauen. Hat jemand eine Peer-to-Peer-Implementierung auf Basis des Frameworks, bin ich gerne bereit mir die anzuschauen und ggf. hinzuzufügen.
  
• Es gibt aktuell genau eine Beispiel-Anwendung: Ein Konsolen-Chatroom. Siehe https://github.com/cgloeckner/networking