git » nmdb » commit 2e4c8bb

Update the design document to reflect the TCP support.

author Alberto Bertogli
2007-06-01 16:06:32 UTC
committer Alberto Bertogli
2007-06-01 16:06:32 UTC
parent d597dc740dd8b1f5d569ed601ab16308d0744110

Update the design document to reflect the TCP support.

Signed-off-by: Alberto Bertogli <albertito@gmail.com>

doc/design.rst +11 -6

diff --git a/doc/design.rst b/doc/design.rst
index a63120c..57ca2ac 100644
--- a/doc/design.rst
+++ b/doc/design.rst
@@ -20,10 +20,13 @@ way.
 Network interface
 =================
 
-The server communicates with its clients using TIPC_ messages, which are
-limited to 66000 bytes in size. It's completely connectionless, and uses the
-reliable datagram layer provided by TIPC_. The network protocol is specified
-in another document, and will not be subject of analysis here.
+The server communicates with its clients using messages, which can be
+delivered through TIPC_ or TCP. Messages are limited by design to 64k so they
+stay inside within TIPC_'s limits.
+
+TIPC_ is completely connectionless, and uses the reliable datagram layer
+provided by TIPC_. The network protocol is specified in another document, and
+will not be subject of analysis here.
 
 The interaction is very simple: the client sends a request message for an
 action, and the server replies to it. There is only one message per request,
@@ -152,12 +155,14 @@ acts upon them internally, but never sends any replies. It is used for
 redundancy purposes, allowing the administrator to have an up-to-date copy of
 the database in case the main one fails.
 
+It only makes sense if used with TIPC_ because it can multicast messages.
+
 The implementation is quite simple, because the code paths are exactly the
 same, with the exception of skipping the network replies, so they're done
 conditionally depending on the passive setting.
 
-Live switching of a server from passive to active (and vice-versa) should be
-possible, although it is not yet implemented.
+Live switching of a server from passive to active (and vice-versa) can be done
+at runtime by sending a *SIGUSR2* signal to the server.
 
 
 The cache layer