Differences

This shows you the differences between two versions of the page.

--- uni:ba:start [2014-03-21 01:54] – created skrupellos
+++ uni:ba:start [2020-11-18 18:11] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
 ====== Bachelor Arbeit ======
+  * [[writer]]
 ===== Komponenten =====
 <code>
@@ Line 21: / Line 22: @@
 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.
 ===== Protokoll =====
-==== Erste Versuche ====
+Die ersten Versuche (Anschrift am Whiteboard), sind als [[protocol_sketch]] gespeichert.
-Kommunikation zwischen //Protocol adapter// und //Dings 1//.
-<code>
-C: register(gameId, playerNr, key, aboState, aboPlayer, aboToPlayer, keepAlive/autoUnregster, Timeout 1, Timeout 2)
-   key: Wenn kein key beim Server für den Player hinterlegt ist (z.B. weil der client einen time out hatte), dann ignoriere den übergebenen key und weise einen neuen zu.
-S: ticket(gameData, playerID, key)/ERR
-   key nicht in to Player, damit keiner Schummeln kann
-   wirklich alles in gameData nötig? (eigentlich nur für web Player)
------- Ab hier ist die Verbindung aufgebaut und folgende Nachrichten können folgen
+Änderungen werden im [[protocol|Working draft]] des Protokolls gemacht.
-C: unregister
+===== Ablauf =====
-   Geschlossene Verbindung nicht hinreichen, da HTTP player auch ohne Verbindung aktiv bleiben muss.
+[[epoll]]
-   Daher "auto unregister" für Protokolle oder "keep alive" für HTTP player.
-S: OK/ERR
-C: move(s)
-   Kann player jeder Zeit senden. Aufforderung zum move, muss Protokoll Adapter anhand von state() erkennen.
-   Zwischen move() und OK/ERR alles state/player()/toPlayer().
-S: OK/ERR
-   Ist das nötig?
-S: state(nr, data)
+<code>
-S: player(nr, data)
+ Thread 1
-   Vor toPlayer(), damit sich state machine drauf einstellen kann.
++--------+
-   Kann "geheime" infos, wie verdekte Karten der Gegner, beinhalten.
+| poll() |         Thread 2
++ - - - -+  --->  +--------+
-S: toPlayer(data)
+| Aktion |     -> | poll() |
-   Flexibler, damit können auch daten zwichen den Zügen an die Player gesendet werden.
+|        |    /   + - - - -+
-   key => (type, value)
+|        |   /    | Aktion |
-   "next" -> int(3)
++--------+ -'     |        |
-   "board" -> array(...)
+                  |        |
+                  +--------+
-C: requestState/Player ???
-S: quit(reason)
 </code>
-==== Geordnet ====
+Aktion kann ohne kontextwechsel ausgeführt werden, sobald blokiert wird, kann weitergearbeitet werden (da mindestens poll() wieder läuft)
-=== Protocol adapter ===
-== ticket ==
+  - **blokierendes select** \\ select() eine der poll Varianten oder libev im one-shot-modus aufrufen und waren bis es sich beendet.
-== toPlayer ==
+  - **Erkennen um welches event es sich handelt/welchen FD**
-== state ==
+    * Signal \\ haben wir hier ein Problem mit mutex?
-== player ==
+      - Ein shutdown flag setzen
+      - alle connections über das shutdown event informieren
+      - alle read polls entfernen (noch noch writes, um das shutdown raus zu schreiben)
+      - sollang fortpflanzen, bis alle write polls weg sind
+      - restliche threads beenden
+    * Thread
+      - Thread in Pool schmeißen
+      - read FD aus thread wieder in poll liste einreihen
+      - weiter pollen
+    * read FD
+      - Thread aus Pool holen
+      - Diesen oder alle read FDs eines games aus queue entfernen
+      - Als neuen poll thread starten
+      - Daten lesen und dem buffer hinzufügen
+      - 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)
+      - 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
+===== Thread Pool =====
+  * 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))
+  * ...
-=== Dings 1 ===
+Ein Thread sollte speichern welche FDs hinzugefügt und entfernt werden sollen von der poll queue.
-== register ==
-== unregister ==
-== move ==
-  ;move %%:%% str
+===== Offene Fragen =====
-  :Der move als text beschreibung. Das spiel muss damit umgehen können. Es wird hier einfach nur durchgereicht.
+  * 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 ?)
-== requestPlayer ==
+===== Links =====
-== requestState ==
+  * D
+    * [[http://code.dlang.org/search|D Packages]]
+    * [[https://github.com/adilbaig/Epoll-D2|epoll]]
+    * [[https://github.com/denizzzka/dpq2|PostgreSQL wraper]]
+    * [[https://github.com/1100110/ZeroMQ|ZeroMQ]]
+  * PostgreSQL
+    * [[http://www.postgresql.org/docs/9.3/static/libpq.html|Library documentation]] (libpq)
+  * epoll
+    * [[http://stackoverflow.com/questions/5541054/how-to-correctly-read-data-when-using-epoll-wait|Multithreaded, level triggered]]
+    * [[http://stackoverflow.com/questions/12481245/epoll-wait-on-several-threads-faster|Multithreaded, edge triggered]]
+    * [[https://groups.google.com/forum/#!topic/linux.kernel/yVkl-7IRKwM|Merkwürdige Probleme]]
+  * libev
+    * [[http://cvs.schmorp.de/libev/|Source]]
+    * [[http://doc.dvgu.ru/devel/ev.html|Documentation]]
+    * [[https://github.com/patrikfors/libev-examples/blob/master/chat-server/chat-server.c|Chat server]]
+  * Misc
+    * [[https://developers.google.com/protocol-buffers/|Protocol Buffers]]
+    * [[https://github.com/brianwatling/libfiber|libfiber]]
+    * [[http://olkhovskiy.me/libevfibers/|libevfibers]]
+    * [[http://thrift.apache.org/|Apache Thrift homepage]]
+    * [[https://github.com/apache/thrift/tree/master/lib/d/src/thrift/server|Apache Thrift source]]
+    * [[http://avro.apache.org/|Apache Avro]]
+    * [[http://zeromq.org/|ZeroMQ]]
+    * [[http://www.kegel.com/c10k.html|The C10K problem]] (wie geht man sinnvoll mit vielen connections um)
+    * [[http://www.aosabook.org/en/nginx.html|Nginx Architektur]]
+    * [[http://www.aosabook.org/en/zeromq.html|ZeroMQ Architektur]]