From c5ca613b8d8a4d3d16495cbf062e183b912b415f Mon Sep 17 00:00:00 2001 From: Jens Thiele Date: Wed, 20 Dec 2006 16:54:20 +0000 Subject: [PATCH] docu --- doc/index.doc | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/doc/index.doc b/doc/index.doc index d3bbadc..b94ca12 100644 --- a/doc/index.doc +++ b/doc/index.doc @@ -10,7 +10,7 @@ \par The figure shows an general overview of the steps involved in a remote procedure call. Using libt2n and its code generator only the server procedure implementations have to be written manually. The stubs are generated by the code generator and the inter-process communication routines are provided by libt2n. libt2n provides an abstract interface for \ref libt2n::connection "connections" - hiding the details of the concrete communication mechanism used. At the moment it is implemented for local sockets (a.k.a "Unix domain sockets") and TCP/IP sockets. + hiding the details of the concrete communication mechanism used. At the moment it is implemented for local sockets (a.k.a "Unix domain sockets") and TCP/IP sockets. (\ref libt2n::socket_client_connection, \ref libt2n::socket_server_connection) \par The client procedure stubs provide an interface to the server procedure implementations. To call the server procedure the client stub procedure is called (step 1). The client stub procedure transforms the procedure arguments and signature including the procedure "name" into a sequence of bytes using boost serialization \ref notes6 "[6]". This byte sequence represents a request to call a procedure with those arguments (step 2). Using the communication routines of libt2n the request is sent to the server. (step 3,4). The server procedure stubs de-serialize the request and call the corresponding server procedure using the reconstructed arguments (step 5). The result of the server procedure is serialized and sent back to the client (steps 6,7,8). Finally the result is de-serialized on client side again and returned to the caller. (steps 9,10). \par -- 1.7.1