docu

[libt2n] / doc / index.doc

diff --git a/doc/index.doc b/doc/index.doc
index d3bbadc..b94ca12 100644 (file)
--- 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