瀏覽代碼

Formatting and doxygen documentation updates

oej 16 年之前
父節點
當前提交
b7e2b56cc2
共有 7 個文件被更改,包括 71 次插入42 次删除
  1. 2 2
      doc/dns.txt
  2. 1 1
      doc/locking.txt
  3. 2 2
      doc/logging-api.txt
  4. 28 23
      doc/modules_init.txt
  5. 7 5
      doc/tcp_tunning.txt
  6. 13 8
      doc/timers.txt
  7. 18 1
      timer.h

+ 2 - 2
doc/dns.txt

@@ -6,8 +6,8 @@
 # 2007-06-18  added naptr & friends, dns_srv_lb, more compile options (andrei)
 #
 
-Overview
---------
+SIP-router and DNS Overview
+---------------------------
 
  The dns subsystem in sip-router can either directly use libresolv and a combination
   of the locally configured dns server, /etc/hosts and the local Network 

+ 1 - 1
doc/locking.txt

@@ -7,7 +7,7 @@
 
 
 SIP-router locking interface
-
+============================
 
 1. Why use it?
 --------------

+ 2 - 2
doc/logging-api.txt

@@ -7,7 +7,7 @@
                          Ondrej Martinek <[email protected]>
                                               January 2009
 
-This document contains the short description of the logging API in SER
+This document contains the short description of the logging API in SIP-router
 for developers.
 
 Source files:
@@ -121,7 +121,7 @@ Source files:
 !!! IMPORTANT! READ ME!
 !!!
 !!!  These changes (mainly the first two) require reformating of the most log
-!!!  messages in SER core and module source files.  This step can be done
+!!!  messages in SIP-router core and module source files.  This step can be done
 !!!  automatically by running "scripts/logging/fix-logs-all" script BUT it
 !!!  was NOT originally performed because it would have generated too many
 !!!  changes in CVS which was discouraged by Andrei.  Instead, the developers

+ 28 - 23
doc/modules_init.txt

@@ -1,40 +1,44 @@
 #$Id$
 #
-# Module intialization description
 #
 # History
 #--------
 #  2007-06-07  created by Andrei Pelinescu <[email protected]>
 #
 
+SIP-router Module intialization description
+===========================================
 
 This document is a very brief overview on what possibilities are for a module
-to run some initializations (or put in another way what's safe and what's
+to run some initializations (or put in another way: What's safe and what's
  not safe to do in mod_init and mod_child_init).
 
 The interesting function are the mod_init (the init_f memeber of
- the module_exports structure) and the mod_child_init (init_child_f in
-  module_exports) functions.
+the module_exports structure) and the mod_child_init (init_child_f in
+module_exports) functions.
 
 mod_init
 --------
 
 mod_init is called after parsing the config, loading all the modules and
- going into daemon mode. mod_init is called in the main process context,
- before changing the uid or gid (so if you want to do something requiring
- higher privileges this is the place to do it). This is not the right place
- to fork  more ser processes, but instead is the only place where one can 
- register future forked processes (see register_procs()).
+going into daemon mode. mod_init is called in the main process context,
+before changing the uid or gid (so if you want to do something requiring
+higher privileges this is the place to do it). This is not the right place
+to fork more SIP-router processes, but instead is the only place where one can 
+register future forked processes (see register_procs()).
+
 mod_init is ideal for initializing per process variables, assuming that you
- don't need different values for each ser child (in which case see mod_child_init below) and shared memory variables assuming that you don't need ser's number of processes (which is not available at this point).
+don't need different values for each SIP-router child (in which case see 
+mod_child_init below) and shared memory variables assuming that you don't 
+need SIP-router's number of processes (which is not available at this point).
 
 
 mod_child_init
 ---------------
 
-mod_child_init is called for each forked ser process with 2 exceptions:
+mod_child_init is called for each forked SIP-router process with 2 exceptions:
  - it's called for the main process too and it's called twice
- - it's not called for ser processes forked with PROC_NOCHLDINIT
+ - it's not called for SIP-router processes forked with PROC_NOCHLDINIT
 
 mod_child_init is always called after mod_init. It takes one parameter, the
  process rank. This parameter can be used to differentiate between normal
@@ -44,7 +48,7 @@ There are two very special rank values: PROC_INIT (as of 2007-06-06) and
 mod_child_init(PROC_INIT) is the first mod_child_init call made, and it's
  guaranteed to happen before any child process is forked. The process context
   is the "main" process (as for mod_init), but this time we have a little bit
- more information: we know the number of ser processes. This is the right
+ more information: we know the number of SIP-router processes. This is the right
   place to initialize things like shared arrays[get_max_procs()].
 Note also that everything done here will be inherited in all the future
  children processes (since it's executed in the "main" process context before
@@ -52,14 +56,14 @@ Note also that everything done here will be inherited in all the future
 
 mod_child_init(PROC_MAIN) is another call that is done in the same "main"
  process context. This call happens just before initializing the main tcp
-  process. This is the only right place for forking more ser processes
+  process. This is the only right place for forking more SIP-router processes
   (see fork_process()). WARNING: the context is the same "main" process as
  for mod_child_init(PROC_INIT) and mod_init() so care must be taken not to
  initialize things twice or three times for the "main" process.
 
 Except for the "main" process case mod_child_init(rank) will be called only
 once for each new child process, just after forking. A positive non-zero rank
- means the current process is a normal ser process and a negative rank has
+ means the current process is a normal SIP-router process and a negative rank has
   some special meaning (grep PROC_ sr_module.h for more info).
 mod_child_init(rank) is the best place for initializing per process variables,
  opening per process database connections, new sockets a.s.o. Note however
@@ -72,15 +76,15 @@ mod_child_init(rank) is the best place for initializing per process variables,
 mod_child_init in the no-fork case
 ----------------------------------
 
-If ser is started in no-fork mode it will try to start as few processes as
+If SIP-router is started in no-fork mode it will try to start as few processes as
 possible (as of this date it will start 3 processes the main process and the
- 2 timers). In this case mod_child_init() will be called 3 times in the
-  same "main" process context: mod_child_init(PROC_INIT);
-  mod_child_init(PROC_MAIN) and mod_child_init(1) (since the first process is
-  also the "main" one).
+2 timers). In this case mod_child_init() will be called 3 times in the
+same "main" process context: mod_child_init(PROC_INIT);
+mod_child_init(PROC_MAIN) and mod_child_init(1) (since the first process is
+also the "main" one).
 
 
-Forking new ser processes from a module
+Forking new SIP-router processes from a module
 ---------------------------------------
 
 static int mod_init()
@@ -133,8 +137,9 @@ mod_child_init(PROC_INIT)
   process.
 
 mod_child_init(PROC_MAIN)
- - the only place from where another ser process can be forked (see fork_process  ()), but remember first to register the number of to-be-forked processes in
-  mod_init()
+ - the only place from where another SIP-router process can be forked 
+   (see fork_process  ()), but remember first to register the number of 
+   to-be-forked processes in mod_init()
 
 mod_child_init(rank!=PROC_INIT && rank!=PROC_MAIN)
  - initialize other per process variables (e.g. different values), whose 

+ 7 - 5
doc/tcp_tunning.txt

@@ -4,20 +4,21 @@
 # --------
 # 2006-01-26  created by andrei
 
-TCP Tunning/monitoring for lots of open connections
+SIP-router TCP Tunning/monitoring for lots of open connections
+==============================================================
 
 0. Introduction
 ----------------
 
 This document describes very briefly various settings that should improve
-ser+tcp performance for sites handling a lot of tcp traffic (> 1000 open
+sip-router+TCP performance for sites handling a lot of TCP traffic (> 1000 open
 connections or very high connection/disconnection rates).
 
 For now it deals only with Linux specific optimizations.
 
 
-1. Useful kernel settings
--------------------------
+1. Useful Linux kernel settings
+-------------------------------
 
 1.1 Connection rate/pending connections: by default the connection rate is
  too small
@@ -32,7 +33,7 @@ net.ipv4.tcp_timestamps        - default on., should be on (along with
 
  Connection should stay as little as possible
  in close_wait to quickly free the fd/resources for new connections attempts
- WARNING: this could break normal tcp use, use it only if you know what you are
+ WARNING: this could break normal TCP use, use it only if you know what you are
   doing
  
 net.ipv4.tcp_max_tw_buckets - maximum number of timewait sockets
@@ -48,6 +49,7 @@ net.ipv4.tcp_syncookies     - default off, in this case it's probably better to
                               keep it off
 
 1.3 Port range
+
 net.ipv4.ip_local_port_range - should be increased (e.g. 4096-65534)
 
 1.4 Open file descriptors

+ 13 - 8
doc/timers.txt

@@ -5,20 +5,25 @@
 # 2005-11-30    created by andrei
 
 
-New timer interface
+SIP-router :: timer interface
+=============================
 
 
 1. Introduction
 ---------------
 
- ser's new timer interface is based on a 3 level hierarchical timing wheel
+SIP-router's timer interface is based on a 3 level hierarchical timing wheel
 (see [1]). Most timeouts will go in the first "wheel" (all timeouts < 1<<14 
- ticks, which by default mean 1024 s). Each wheel acts as a circular buffer.
- The big advantage of this scheme is that most of the time you just run all the timer handlers from the current entry in the first wheel (no comparisons necessary). Each 2^14 ticks, all the timers in the second wheel's current entry are redistributed and each 2^23 ticks all the timers in the third wheel's current entry are redistributed.
+ticks, which by default mean 1024 s). Each wheel acts as a circular buffer.
+The big advantage of this scheme is that most of the time you just run all the 
+timer handlers from the current entry in the first wheel (no comparisons necessary). 
+Each 2^14 ticks, all the timers in the second wheel's current entry are redistributed 
+and each 2^23 ticks all the timers in the third wheel's current entry are redistributed.
 
- The new timer interfaces allows adding timers dynamically, supports one shot
- and periodic timers, is precise and fast (very low overhead) and supports
-"fast" and "slow" timers. For now it uses setitimer to "generate" the ticks and form time to time it re-adjusts them based on the real system time.
+The timer interfaces allows adding timers dynamically, supports one shot
+and periodic timers, is precise and fast (very low overhead) and supports
+"fast" and "slow" timers. For now it uses setitimer to "generate" the ticks and from 
+time to time it re-adjusts them based on the real system time.
 
 
 [1] - G. Varghese, T. Lauck,  Hashed and Hierarchical Timing Wheels: Efficient
@@ -29,7 +34,7 @@ New timer interface
 -----------------
 
 All the public functions are defined in timer.h. timer_ticks.h contains
- ticks conversion related macros (ticks to seconds, ms or viceversa).
+ticks conversion related macros (ticks to seconds, ms or viceversa).
 
 
 3. Example usage

+ 18 - 1
timer.h

@@ -29,7 +29,24 @@
  */
 /* History:
  * --------
- *  2005-07-27  complete re-design/re-implemnetation (andrei)
+ *  2005-07-27  complete re-design/re-implementation (andrei)
+ */
+
+/**
+ * @file
+ * @brief SIP-router core :: timer related functions (public interface)
+ * @ingroup core
+ *
+ * Module: \ref core
+ *
+ * - \ref TimerDoc
+ */
+
+
+/**
+ * @page TimerDoc SIP-router's timer documentation
+ * @verbinclude timers.txt
+ *
  */