more documentation

1 files changed, 61 insertions, 0 deletions

diff --git a/docs/network/FINDINGS_PROACTOR_PAPER b/docs/network/FINDINGS_PROACTOR_PAPER
new file mode 100644
index 0000000..f04ab02
--- /dev/null
+++ b/docs/network/FINDINGS_PROACTOR_PAPER
@@ -0,0 +1,61 @@
+- one thread per potential and actual connection, doing accept/connect and
+  all operations like read/write to socket/file/pipe whatever and does
+  all the processing.
+  + simple application code
+  - CPU/thread mismatch, in generall we get too many threads compared to
+    the number of available CPUs, thus higher costs for task switches
+  - shared resources need more synchronization and can become hot spots
+  - threading is different, and sometimes not available, networking should
+    be independent on the fact whether we want to use threads or not
+    (orthogonal design)
+- Reactor, Acceptor/Connector registers to reactor (only for the readyness),
+  central event dispatcher
+  + one thread, good as no sycnhronization needed, but can't be easily
+    scaled (especially fairly!)
+  - complicated code, cooperative system, quite easy to get DoSAs this way,
+    everything has to bee non-blocking, this can cause portability problem:
+    we take asynchronizity if available as performance optimization, but
+    it's bad to rely on it (see tests with /dev/zero on some Unixes and
+    especially Windows which doesn't support Asio on some devices)
+  - POSIX select is hard to split accross many threads, so the risk is to
+    get a central thread as bottleneck
+  - portability can be a problem: we have to port the proactor and the
+    event handlers (think reading from a file asynchronusly on Unix
+    and Windows)
+- Proactor: one to many threads report completion of asynchonous events,
+  we can have parallel I/O operations without the need of threads
+  - debugging is hard, but as we gona do finite state machines for
+    the protocol anyway, this is not really an issue (design and verify
+    correctness, don't debug!)
+  - synchronous events must be made asynchronous
+  + ASIO is THE model on Windows for all files (and almost everything is
+    a file there), also with upcoming POSIX asio and some Unix-specific
+    asio models (like Solaris /dev/poll) this is the future architecture
+    anyway.
+  + better isolation of problems: "asynchronous O/S-near operations" and
+    "application operations", concurrency strategies should be a parallel
+    aspect to the problem
+  + better OS-abstraction possible as with reactor or multi-thread model,
+    especially calls like async_write, signals etc. are platform-dependend
+  - cancelation of running operations and priorization may be a little bit
+    tricky
+
+- Mmh. This gives us the idea that the networking layer and some other
+  components register to the Proactor system
+
+- Proactor
+
+Connector/Acceptor
+- decouple communication establishment/interruption which happens orthogonal
+  to the protocol communication above
+- connection esablishment can also be unicast, broadcast, multicast, this
+  could come handy
+- different life-time, connect/accepts don't change so often as protocol
+  to implement
+- differ between connection roles (which are always client/server) and
+  communication roles (which can be the same or reversed, can change during
+  a communication session or can be completly peer-to-peer)
+- connect and accept vary heavily between Unixes and Windows
+  Connector and Acceptor abstract factories with concrete factories and
+  connections as for TCP/IP
+- mmh. how is closing of connections handled? errors, etc.