Changeset 2:d8ce06172629 in freeDiameter for include/freeDiameter/libfreeDiameter.h

Timestamp:

Aug 31, 2009, 5:32:22 PM (15 years ago)

Author:

Sebastien Decugis <sdecugis@nict.go.jp>

Branch:

default

Phase:

public

Message:

Added a global debug level var

File:

• include/freeDiameter/libfreeDiameter.h (modified) (7 diffs)

include/freeDiameter/libfreeDiameter.h

@@ -122 +122 @@
 char * fd_log_time ( char * buf, size_t len );
 
-/************************** DEBUG MACROS ************************************/
 
 /* levels definitions */
@@ -137 +136 @@
 #endif /* TRACE_LEVEL */
 
-/* The level of the file being compiled */
+/* The level of the file being compiled. */
 static int local_debug_level = TRACE_LEVEL;
 
-/* helper macros (pre-processor hacks) */
+/* A global level, changed by configuration or cmd line for example. default is 0. */
+extern int fd_g_debug_lvl;
+
+/* helper macros (pre-processor hacks to allow macro arguments) */
 #define __str( arg )  #arg
 #define _stringize( arg ) __str( arg )
@@ -146 +148 @@
 #define _aggregate( arg1, arg2 ) __agr( arg1, arg2 )
 
-/* Some portability tricks to get nice function name in __PRETTY_FUNCTION__ */
+/* Some portability code to get nice function name in __PRETTY_FUNCTION__ */
 #if __STDC_VERSION__ < 199901L
 # if __GNUC__ >= 2
@@ -159 +161 @@
 
 /* Boolean for tracing at a certain level */
-#define TRACE_BOOL(_level_) ( (_level_) <= local_debug_level )
-
-/* The general debug macro, each call results in two lines of debug messages */
+#define TRACE_BOOL(_level_) ( (_level_) <= local_debug_level + fd_g_debug_lvl )
+
+/* The general debug macro, each call results in two lines of debug messages (change the macro for more compact output) */
 #define TRACE_DEBUG(level,format,args... ) {                                                                                    \
         if ( TRACE_BOOL(level) ) {                                                                                              \
@@ -173 +175 @@
 }
 
-/* Helper for function entry */
+/* Helper for function entry -- for very detailed trace of the execution */
 #define TRACE_ENTRY(_format,_args... ) \
         TRACE_DEBUG(FCTS, "->%s (" #_args ") = (" _format ") >", __PRETTY_FUNCTION__, ##_args );
 
-/* Helper for debugging by adding traces */
+/* Helper for debugging by adding traces -- for debuging a specific location of the code */
 #define TRACE_HERE()    \
-        TRACE_DEBUG(INFO, " -- debug checkpoint -- ");
-
-/* Helper for tracing the CHECK_* macros bellow */
+        TRACE_DEBUG(NONE, " -- debug checkpoint -- ");
+
+/* Helper for tracing the CHECK_* macros bellow -- very very verbose code execution! */
 #define TRACE_DEBUG_ALL( str )  \
         TRACE_DEBUG(CALL, str );
@@ -403 +405 @@
 }
 
-/* Cleanups for cancellation (all threads should be safely cancelable!) */
+/* Cleanups for cancellation (all threads should be safely cancelable...) */
 static __inline__ void fd_cleanup_mutex( void * mutex )
 {
@@ -1274 +1276 @@
 #define ER_DIAMETER_REDIRECT_INDICATION         3006
 
-/* Iterator on the rules of a parent object */
-int fd_dict_iterate_rules ( struct dict_object *parent, void * data, int (*cb)(void *, struct dict_rule_data *) );
+
+/*============================================================*/
+/*                         SESSIONS                           */
+/*============================================================*/
+
+
+
+/*
+ * The libfreeDiameter does not provide a full support of the sessions state machines as described in the RFC3588.
+ * It only provides a basic support allowing an extension to associate some state with a session identifier, and retrieve 
+ * this data later.
+ *
+ * A session is an opaque object, associated with a value of a Session-Id AVP.
+ * An extension that wants to associate data with the session must first register as session module client 
+ * with the sess_regext function to get an identifier object (sess_reg_t).
+ * 
+ * The module manages tuplets ( sess_id_t *, sess_reg_t *, void *). The following functions are used to manage these tuplets:
+ * sess_data_reg  : associate a pointer with a given session for a given module client.
+ * sess_data_dereg: removes an association.
+ * sess_data_get  : get the pointer associated with an association without changing it.
+ *
+ * Note that creating an association calls sess_link as a side effect, and removing the association calls sess_unlink.
+ *
+ * QUICK TUTORIAL:
+ *  For an extension that wants to implement a session state machine, here is a quick guide.
+ *
+ * First, the extension must define a structure to save the session state, for example appstate_t.
+ *
+ * Since the extension will use the session module, it creates a sess_reg_t by calling sess_regext.
+ *
+ * If the extension behaves as a client, it receives external events that trig the start of a new sessions.
+ * When such event occurs, the extension calls sess_new with the appropriate parameters to create a new session.
+ * It initializes an appstate_t structure with the data of this session and creates an association with sess_data_reg (%).
+ * Then it creates a message (application-specific) to request authentication and/or authorization for the service
+ * and the message is sent.
+ *
+ * Later, assuming that the extension has registered appropriate callbacks in the dispatcher module, when a message
+ * is received, the extension can retrieve the state of the session with the sess_data_get function.
+ *
+ * Finaly, when the extension decides to terminate the session (timer, or as result of a message exchange), it
+ * calls sess_data_dereg in order to destroy the binding in the daemon. When last message refering this session is freed,
+ * the session data is freed.
+ *
+ * (%) A this time, the extension must call sess_unlink in order to counter the effects of the sess_new function.
+ * This allows to have the session destroyed when no more data is associated to it.
+
+
+
+/*============================================================*/
+/*                         DISPATCH                           */
+/*============================================================*/
+
+/* The dispatch process consists in passing a message to some handlers
+ (typically provided by extensions) based on its content (app id, cmd code...) */
+
+/* The dispatch module has two main roles:
+ *  - help determine if a message can be handled locally (during the routing step)
+ *  - pass the message to the callback(s) that will handle it (during the dispatch step)
+ *
+ * These are the possibilities for registering a callback:
+ *
+ * -> For All messages.
+ *  This callback is called for all messages that are handled locally. This should be used only
+ *  internally by the daemon, or for debug purpose.
+ *
+ * -> by AVP value (constants).
+ *  This callback will be called when a message is received and contains a certain AVP with a specified value.
+ *
+ * -> by AVP.
+ *  This callback will be called when the received message contains a certain AVP.
+ *
+ * -> by command-code.
+ *  This callback will be called when the message is a specific command.
+ *
+ * -> by application.
+ *  This callback will be called when the message has a specific application-id.
+ *
+ * ( by vendor: would this be useful? it may be added later)
+ *
+ * Note that several criteria may be selected at the same time, for example command-code AND application id.
+ *
+ * When a callback is called, it receives the message as parameter, and eventually a pointer to 
+ * the AVP in the message when this is appropriate.
+ *
+ * The callback must process the message, and eventually create an answer to it. See the definition
+ * bellow for more information.
+ *
+ * If no callback has handled the message, a default handler will be called with the effect of
+ * requeuing the message for forwarding on the network to another peer (for requests, if possible), or 
+ * discarding the message (for answers).
+ */
+
+