From 57898d7986de91792d725e2c4c1e648aa90dec43 Mon Sep 17 00:00:00 2001 From: Andreas Baumann Date: Tue, 7 Apr 2009 16:04:09 +0200 Subject: more documentation --- docs/network/FINDINGS_PROACTOR_PAPER | 61 ++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 docs/network/FINDINGS_PROACTOR_PAPER (limited to 'docs') 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. -- cgit v1.2.3-54-g00ecf