Socket/Protocols/Inet: Fix off-by-one error in INet6Address
[senf.git] / PPI / Mainpage.dox
index cd3167e..8ab4d4b 100644 (file)
@@ -61,6 +61,7 @@
     <li>\ref ppi_connections</li>
     <li>\ref ppi_throttling</li>
     <li>\ref ppi_events</li>
+    <li>\ref ppi_run</li>
     <li>\ref ppi_flows</li>
     </ol>
     </div>
     Of these modules, normally only the application modules need to be implemented since the library
     provides an extensive set of reusable modules.
     
-    The following example module declares three \ref ppi_connectors: \c payload, \c stuffing and
-    \coutput. These connectors are defined as \e public data members so they can be accessed from
-    the outside. This is important as we will see below.
+    The following example module declares three \ref ppi_connectors "Connectors": \c payload, 
+    \c stuffing and \c output. These connectors are defined as \e public data members so they
+    can be accessed from the outside. This is important as we will see below.
 
     \code
       class RateStuffer
     example by manually throttling some passive connector (see \ref
     senf::ppi::connector::PassiveConnector). 
 
-    To enable/disable automatic throttling, the \ref senf::ppi::Module::route() command returns a
-    reference to a \ref senf::ppi::Route instance. If this route is \e forwarding route, (that is,
-    of the connectors is passive and the other is active), the return value will be derived from
-    \ref senf::ppi::ForwardingRoute which provides members to control the throttle notification
-    forwarding.
+    To enable/disable automatic throttling, the \ref senf::ppi::module::Module::route() command 
+    returns a reference to a \ref senf::ppi::Route instance. If this route is \e forwarding route,
+    (that is, of the connectors is passive and the other is active), the return value will be 
+    derived from \ref senf::ppi::ForwardingRoute which provides members to control the throttle
+    notification forwarding.
     
     \see 
         senf::ppi::module::Module \n
 
     \see senf::ppi::EventDescriptor
 
+    \section ppi_run Running the network
+
+    After the network has been set up, senf::ppi::run() is called to execute it. This call will only
+    return after all data has been processed. The PPI knows this, when no events are enabled any
+    more. Without events, nothing will happen any more since it is the events which drive the
+    PPI. Therefore the PPI surmises, that all data has been processed and returns from
+    senf::ppi::run().
+
+    This works very well with automatic throttling. When no data is available to be processed any
+    more and no more data can be expected to arrive (for Example since data has been read from a
+    file which is now exhausted) all events will be disabled automatically via trhottle
+    notifications and so signal that any processing should stop.
+
     \section ppi_flows Information Flow
 
     The above description conceptually introduces three different flow levels: