SG_BEGIN_DECL()
/** @addtogroup GRAS_dd Data description
- * @brief Describing data to be exchanged (Communication facility)
+ * @brief Describing data to be exchanged
*
* Since GRAS takes care of potential representation conversion when the platform is heterogeneous,
* any data which transits on the network must be described beforehand.
/** @defgroup GRAS_dd_manual Simple manual data description
* @ingroup GRAS_dd
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]::[\ref GRAS_dd]
- * <tr><td><b>Prev</b> <td> [\ref GRAS_dd_auto]
- * <tr><td><b>Next</b> <td> [\ref GRAS_dd_cb_simple] </table></center>
*
* Here are the functions to use if you want to declare your description manually.
* The function names should be self-explanatory in most cases.
/** @defgroup GRAS_dd_cb_simple Data description with Callback Persistant State: Simple push/pop mechanism
* @ingroup GRAS_dd
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]::[\ref GRAS_dd]
- * <tr><td><b>Prev</b> <td> [\ref GRAS_dd_manual]
- * <tr><td><b>Next</b> <td> [\ref GRAS_dd_cb_full] </table></center>
*
* Sometimes, one of the callbacks need to leave information for the next ones. If this is a simple integer (such as
* an array size), you can use the functions described here. If not, you'll have to play with the complete cbps interface.
*
+ * \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Simple push/pop Callback State" -->\endhtmlonly
*
* Here is an example:\verbatim
struct s_array {
/** @defgroup GRAS_dd_cb_full Data description with Callback Persistant State: Full featured interface
* @ingroup GRAS_dd
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]::[\ref GRAS_dd]
- * <tr><td><b>Prev</b> <td> [\ref GRAS_dd_cb_simple]
- * <tr><td>Next <td> </table></center>
*
- * Sometimes, one of the callbacks need to leave information for the next ones. If the simple push/pop mechanism
- * introduced in previous section isn't enough, you can always use this full featured one.
+ * Sometimes, one of the callbacks need to leave information for the next
+ * ones. If the simple push/pop mechanism introduced in previous section
+ * isn't enough, you can always use this full featured one. The bad point is
+ * that it is quite badly documented...
+ *
+ * \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Full featured Callback State" -->\endhtmlonly
+ *
*/
/* @{ */
/** @addtogroup GRAS_emul
* @brief Code execution "emulation" and "virtualization".
*
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]
- * <tr><td><b>Prev</b> <td> [\ref GRAS_globals]
- * <tr><td><b>Next</b> <td> [\ref GRAS_main_generation] </table></center>
- *
* Emulation and virtualization words have a lot of different meanings in
* computer science. Here is what we mean, and what this module allows you
* to do (if it does not match your personal belives, I'm sorry):
SG_BEGIN_DECL()
/** @addtogroup GRAS_msg
- * @brief Defining messages and callbacks, and exchanging messages (Communication facility)
+ * @brief Defining messages and callbacks, and exchanging messages
*
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]
- * <tr><td><b>Prev</b> <td> [\ref GRAS_sock]
- * <tr><td><b>Next</b> <td> [\ref GRAS_timer]
- * <tr><td><b>Down</b> <td> [\ref GRAS_msg_decl] </table></center>
- *
* There is two way to receive messages in GRAS. The first one is to
* register a given function as callback to a given type of messages (see
* \ref gras_cb_register and associated section). But you can also
*
* Usually, both ways are not intended to be mixed of a given type of
* messages. But if you do so, it shouldn't trigger any issue. If the
- * message arrives when gras_msg_wait is blocked, then it will be routed
- * to it. If it arrives when before or after gras_msg_wait, it will be
+ * message arrives when gras_msg_wait is blocked, then it will be routed to
+ * it. If it arrives when before or after \ref gras_msg_wait, it will be
* passed to the callback.
*
* For an example of use, please refer to \ref GRAS_ex_ping.
/** @defgroup GRAS_msg_decl Message declaration and retrival
* @ingroup GRAS_msg
*
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]::[\ref GRAS_msg]
- * <tr><td> Prev <td>
- * <tr><td><b>Next</b> <td> [\ref GRAS_msg_cb] </table></center>
+ * GRAS messages can only accept one type of payload. See \ref GRAS_dd for
+ * more information on how to describe data in GRAS.
*
- * GRAS messages can only accept one type of payload. If you absolutely want to declare a message
- * able to convey several datatypes, you can always say that it conveys a generic reference (see
+ * If you absolutely want use a message able to convey several datatypes,
+ * you can always say that it conveys a generic reference (see
* \ref gras_datadesc_ref_generic).
*
* In order to ease the upgrade of GRAS applications, it is possible to \e version the messages, ie
/** @defgroup GRAS_msg_cb Callback declaration and use
* @ingroup GRAS_msg
*
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]::[\ref GRAS_msg]
- * <tr><td><b>Prev</b> <td> [\ref GRAS_msg_decl]
- * <tr><td><b>Next</b> <td> [\ref GRAS_msg_exchange] </table></center>
*
* This is how to register a given function so that it gets called when a
* given type of message arrives.
/** @defgroup GRAS_msg_exchange Message exchange
* @ingroup GRAS_msg
*
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]::[\ref GRAS_msg]
- * <tr><td><b>Prev</b> <td> [\ref GRAS_msg_cb]
- * <tr><td> Next <td> </table></center>
*/
/** @{ */
/****************************************************************************/
/** \addtogroup GRAS_globals
- * \brief Handling global variables so that it works on simulator (Virtualization).
+ * \brief Handling global variables so that it works on simulator.
*
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]
- * <tr><td><b>Prev</b> <td> [\ref GRAS_virtu]
- * <tr><td><b>Next</b> <td> [\ref GRAS_emul] </table></center>
- *
* In GRAS, using globals is forbidden since the "processes" will
* sometimes run as a thread inside the same process (namely, in
* simulation mode). So, you have to put all globals in a structure, and
SG_BEGIN_DECL()
/** @addtogroup GRAS_timer
- * @brief Delayed and repetitive tasks (Communication facility)
- *
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]
- * <tr><td><b>Prev</b> <td> [\ref GRAS_msg]
- * <tr><td><b>Next</b> <td> [\ref GRAS_virtu] </table></center>
+ * @brief Delayed and repetitive tasks
*
* This is how to have a specific function called only once after the
* specified amount of time or a function executed every 5 mn until it gets
+
/* $Id$ */
/* transport - low level communication (send/receive bunches of bytes) */
#define GRAS_TRANSPORT_H
/** \addtogroup GRAS_sock
- * \brief Socket handling (Communication facility).
+ * \brief Socket handling
*
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]
- * <tr><td><b>Prev</b> <td> [\ref GRAS_dd]
- * <tr><td><b>Next</b> <td> [\ref GRAS_msg]
- * <tr><td><b>Down</b> <td> [\ref GRAS_sock_create] </table></center>
+ * The model of communications in GRAS is very close to the BSD socket one.
+ * To get two hosts exchanging data, one of them need to open a
+ * <i>server</i> socket on which it can listen for incoming messages and the
+ * other one must connect a <i>client</i> socket onto the server one.
*
- * The model of communications in GRAS is very close to the BSD socket one. To get two hosts
- * exchanging data, one of them need to open a <i>server</i> socket on which it can listen for incoming messages
- * and the other one must connect a <i>client</i> socket onto the server one.
+ * The main difference is that you cannot exchange arbitrary bytes on
+ * sockets, but messages. See the \ref GRAS_msg section for details.
*
- * If you need an example of this, check \ref GRAS_ex_ping.
+ * If you need an example of how to use sockets, check \ref GRAS_ex_ping.
*
*/
/** \defgroup GRAS_sock_create Socket creation functions
* \ingroup GRAS_sock
*
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]::[\ref GRAS_sock]
- * <tr><td>Prev <td>
- * <tr><td><b>Next</b> <td> [\ref GRAS_sock_info] </table></center>
*/
/* @{*/
/** \brief Opaque type describing a socket */
/** \defgroup GRAS_sock_info Retrieving data about sockets and peers
* \ingroup GRAS_sock
*
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]::[\ref GRAS_sock]
- * <tr><td><b>Prev</b> <td> [\ref GRAS_sock_create]
- * <tr><td><b>Next</b> <td> [\ref GRAS_sock_meas] </table></center>
- *
* Who are you talking to?
*/
/* @{*/
/** \defgroup GRAS_sock_meas Using measurement sockets
* \ingroup GRAS_sock
*
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]::[\ref GRAS_sock]
- * <tr><td><b>Prev</b> <td> [\ref GRAS_sock_info]
- * <tr><td><b>Next</b> <td> [\ref GRAS_sock_file] </table></center>
- *
* You may want to use sockets not to exchange valuable data (in messages),
* but to conduct some bandwidth measurements and related experiments. If so, try those measurement sockets.
*
/** \defgroup GRAS_sock_file Using files as sockets
* \ingroup GRAS_sock
*
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]::[\ref GRAS_sock]
- * <tr><td><b>Prev</b> <td> [\ref GRAS_sock_meas]
- * <tr><td>Next <td> </table></center>
*
* For debugging purpose, it is possible to deal with files as if they were sockets.
* It can even be useful to store stuff in a portable manner, but writing messages to a file
SG_BEGIN_DECL()
/** @addtogroup GRAS_virtu
- * @brief System call abstraction layer (Virtualization).
+ * @brief System call abstraction layer.
*
- * <center><table><tr><td><b>Top</b> <td> [\ref index]::[\ref GRAS_API]
- * <tr><td><b>Prev</b> <td> [\ref GRAS_timer]
- * <tr><td><b>Next</b> <td> [\ref GRAS_globals] </table></center>
*
* @{
*/
