docu updates
[libt2n] / doc / index.doc
index 2c83e3f..874f67d 100644 (file)
@@ -1,32 +1,57 @@
-// mainpage should not be here
-
 /*! \mainpage libt2n - (talk to neighbor)
  \section intro_sec Introduction
- libt2n (talk to neighbor) is a C++ library for inter-process communication (IPC, s.a. http://en.wikipedia.org/wiki/Inter-process_communication)
- with an additional code generator to make remote procedure calls simple. 
- \par 
- XXX: improve this paragraph: The input for the code generator is standard C++ code (in fact we use gccxml to parse the C++ code and the code generator takes the XML as input) and you mark the procedures you want to expose to other processes.
- It then generates the stubs needed.
- The exported procedures can be grouped. For each group the code generator is called and generates 6 output files: group_common.hxx, group_common.cpp, group_client.hxx, group_client.cpp, group_server.hxx, group_server.cpp. The _common files are used by client and server whereas the _client files are used by the client and the _server files by the server only.
+ \par
+ libt2n (talk to neighbor) is a C++ library for inter-process communication (IPC \ref notes1 "[1]") with an additional code generator (libt2n-codegen) to make C++ remote procedure calls (RPC \ref notes2 "[2]")  simple.
+  \htmlonly    
+  <p><img src="http://jan.netcomp.monash.edu.au/webservices/rpc_stub.png" alt="rpc"/></p>
+  \endhtmlonly
+ \par
+ Figure: Remote procedure call overview \ref notes3 "[3]"
+ \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.
+ \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
+ The input for the code generator is standard C++ code
+       \ref notes4 "[4]"
+ and you mark the procedures you want to expose to other processes. Because the interface is described in C++ directly there is no need for a interface description language (IDL, \ref notes5 "[5]").
+ The code generator is used to create the client and server stubs for the marked procedures. The procedures can be grouped and each group maps to two classes (cmd_group_... and cmd_group_..._client). The cmd_group_..._client class provides the interface to call remote procedures. Each remote procedure maps to a method of this class and the constructor takes a connection object establishing the binding to the remote side. For each group the code generator is called and generates 6 output files: group_common.hxx, group_common.cpp, group_client.hxx, group_client.cpp, group_server.hxx, group_server.cpp. The _common files are used by client and server whereas the _client files contain the client stub code (the cmd_group_..._client class) and the _server files the server stub code. 
  \par
  To simplify the build process a Makefile snippet is provided that allows to create a server program and a client library (including a corresponding .pc file) using the autotools easily.
  \section install_sec Installation
 
  \subsection requirements Requirements
+ \par libt2n
  - boost <http://www.boost.org/> (serialization <http://www.boost.org/libs/serialization/doc/>)
+ \par libt2n-codegen
  - gccxml <http://www.gccxml.org>
  - libxmlpp <http://libxmlplusplus.sourceforge.net/>
 
  \subsection recommended Recommended
  - pkg-config <http://pkgconfig.freedesktop.org/wiki/>
- - autotools (automake, autoconf, libtool)
+ - autotools (autoconf <http://www.gnu.org/software/autoconf/>, automake, libtool)
 
  \subsection Compilation
  \verbatim
- ./configure && make install
+ ./configure && make check && make install
  \endverbatim
 
  \subsection Usage
  Take a look at the example file:../../../libt2n-examples/doc/html/index.html
 
+ \subsection References
+ - \anchor notes1
+ [1] inter-process communication (IPC), http://en.wikipedia.org/wiki/Inter-process_communication
+ - \anchor notes2
+ [2] remote procedure call (RPC), http://en.wikipedia.org/wiki/Remote_procedure_call and "THE RPC MODEL" http://www.faqs.org/rfcs/rfc1050.html
+ - \anchor notes3
+ [3] Figure: Remote procedure call overview, http://jan.netcomp.monash.edu.au/webservices/rpc_stub.png, Jan Newmarch "Web services" http://jan.netcomp.monash.edu.au/webservices/tutorial.html
+ - \anchor notes4
+ [4] in fact gccxml is used to parse the C++ code and the XML output of gccxml is used as input for the code generator
+ - \anchor notes5
+ [5] interface description language (IDL), http://en.wikipedia.org/wiki/Interface_description_language
+ - \anchor notes6
+ [6] boost serialization, http://www.boost.org/libs/serialization/doc/
 */