• Writer

     Client                   Protocol adapter                        Dings 1                         Game State
+--------------+              +---------------+   Unix Socket    +---------------+                     +------+
|              |    TCP/IP    |               | ---------------> | State Machine |   Funktionsaufruf   |      |
|  Black Box   | <----------> | State machine |                  |               | <-----------------> |Object|
| (Von Studis) |   messages   |               | <--------------- |     Buffer    |                     |      |
+--------------+              +---------------+     messages     +---------------+                     +------+

+-- Prozess ---+              +--- Prozess ---+                  +-------------------- Prozess ---------------+
+-- Maschiene -+              +-------------------------------------- Maschiene ------------------------------+
+--------------------------------------------------- System --------------------------------------------------+

Die Kommunikation wird immer enger/direkter.

1. Zwischen Prozessen auf verschiedenen Maschienen
2. Zwischen Prozessen auf der selben Maschiene
3. Innerhalb eines Prozesses

Verliert der Protokoll adapter die Verbindung zum master und wartet er noch auf eine Antwort von ihm, so ist vmtl. er am Absturz schuld und baut keine erneute Verbindung auf.

Die ersten Versuche (Anschrift am Whiteboard), sind als Protocol sketch gespeichert.

Änderungen werden im Working draft des Protokolls gemacht.

epoll

 Thread 1
+--------+
| poll() |         Thread 2
+ - - - -+  --->  +--------+
| Aktion |     -> | poll() |
|        |    /   + - - - -+
|        |   /    | Aktion |
+--------+ -'     |        |
                  |        |
                  +--------+

Aktion kann ohne kontextwechsel ausgeführt werden, sobald blokiert wird, kann weitergearbeitet werden (da mindestens poll() wieder läuft)

1. blokierendes select
   select() eine der poll Varianten oder libev im one-shot-modus aufrufen und waren bis es sich beendet.
2. Erkennen um welches event es sich handelt/welchen FD
   • Signal
     haben wir hier ein Problem mit mutex?
     1. Ein shutdown flag setzen
     2. alle connections über das shutdown event informieren
     3. alle read polls entfernen (noch noch writes, um das shutdown raus zu schreiben)
     4. sollang fortpflanzen, bis alle write polls weg sind
     5. restliche threads beenden
   • Thread
     1. Thread in Pool schmeißen
     2. read FD aus thread wieder in poll liste einreihen
     3. weiter pollen
   • read FD
     1. Thread aus Pool holen
     2. Diesen oder alle read FDs eines games aus queue entfernen
     3. Als neuen poll thread starten
     4. Daten lesen und dem buffer hinzufügen
     5. Loop über alle vollständigen messages (oder ein libev “reset” reset der fairness halber (FDs entfernen/hinzufügen?)): aktion ausführen (im selben thread, in einem weiteren wird ja schon wieder rumgepollt)
     6. Den Pointer des Threads in den Thread FD schreiben

Beim schreiben locks auf buffer verwenden, da mehrere threads schreiben können sowie mehrere schreiben und einer lesen kann.

immer ein non blocking write versuchen (damit es sofort los geht), alles was nicht geschrieben werden konnte in buffer einfügen. Sollte der buffer voll sein, müssen alle reads des games beendet werden

• LL für aktive und wartende (also alle) Threads, damit GC nicht zuschlägt.
• double LL für die aktiven, damit man mittig einen fertigen Thread raus reisen kann.
• FIFO für die wawrtenden, damit eine gleichmäsige “abnutzung” der Threads stattfindet.
• Muss nicht thread save sein, solange LL und counter änderungen vor den starten eines neuen poll threads passieren und nur der poll thread die aktionen durchführt.

Wann sollen erzeugungs/löschungs aufgaben durchgeführt werden (ausnamne die notfallerzeugung beim rausnehmen, wenn keine wartenden)?

• erzeugen/löschen beim rausnehmen (verzögert Abarbeitung der Aufgaben)
• erzeugen/löschen beim zurücklegen (da wäre zeit, aber wenn nur konsumiert wird, werden keine spares erzeugt (was ja eigentlich nicht schlim ist, da er ja eht zu tun hat))
• …

Ein Thread sollte speichern welche FDs hinzugefügt und entfernt werden sollen von der poll queue.

• Wer setzt den thinking timeout durch? (Protocol adapter, dann brauch das game selbst keine timeouts?)
• Wie wird der write abfluss sicher gestellt (blocken des schreibers bei flush() hilft nicht, ein anderer player auf einem anderen thread schon weiter machen kann) (Lösung libev subqueues ?)

• D
  • D Packages
  • epoll
  • PostgreSQL wraper
  • ZeroMQ
• PostgreSQL
  • Library documentation (libpq)
• epoll
  • Multithreaded, level triggered
  • Multithreaded, edge triggered
  • Merkwürdige Probleme
• libev
  • Source
  • Documentation
  • Chat server
• Misc
  • Protocol Buffers
  • libfiber
  • libevfibers
  • Apache Thrift homepage
  • Apache Thrift source
  • Apache Avro
  • ZeroMQ
  • The C10K problem (wie geht man sinnvoll mit vielen connections um)
  • Nginx Architektur
  • ZeroMQ Architektur