-// Copyright (C) 2007
-// Fraunhofer Institut fuer offene Kommunikationssysteme (FOKUS)
-// Kompetenzzentrum fuer Satelitenkommunikation (SatCom)
+// $Id$
+//
+// Copyright (C) 2007
+// Fraunhofer Institute for Open Communication Systems (FOKUS)
+// Competence Center NETwork research (NET), St. Augustin, GERMANY
// Stefan Bund <g0dil@berlios.de>
//
// This program is free software; you can redistribute it and/or modify
\brief Module public header
*/
-#ifndef HH_Module_
-#define HH_Module_ 1
+#ifndef HH_SENF_PPI_Module_
+#define HH_SENF_PPI_Module_ 1
// Custom includes
#include <vector>
#include <boost/ptr_container/ptr_vector.hpp>
#include "../Scheduler/ClockService.hh"
#include "predecl.hh"
+#include "ModuleManager.hh"
//#include "Module.mpp"
///////////////////////////////hh.p////////////////////////////////////////
The PPI provided general purpose modules can be grouped into several categories
\li \ref io_modules receive external data or forward packets out of the PPI
- \li \ref sourcesink_modules generate or absorb packets internally
\li \ref routing_modules forward packets within the network
\li \ref adapter_modules are used to connect incompatible connectors to each other
\todo Implement Spliters: PassiveSplitter, PrioritySplitter, CloneSplitter
*/
- /** \defgroup io_modules Input/Output Modules
-
- Input/Output Modules receive data from external sources or forward data from the PPI to
- outside targets.
- */
-
- /** \defgroup sourcesink_modules Source/Sink Modules
+ /** \defgroup io_modules Source/Sink Modules
- Source and Sink modules generate or absorb packets internally. In contrast to \ref
- io_modules, they do not communicate outside the PPI.
+ Source and Sink modules generate or absorb packets in some way: Reading data from a file
+ descriptor, discarding packets etc.
*/
/** \defgroup routing_modules Routing Modules
public:
// Define connectors. Any number and type of connectors may be defined. Connectors
// must be public since they need to be accessed to connect modules with each other.
- senf::ppi::connector::PassiveInput input;
- senf::ppi::connector::ActiveOutput output;
+ senf::ppi::connector::PassiveInput<> input;
+ senf::ppi::connector::ActiveOutput<> output;
SomeModule(senf::FileHandle h)
: handle ( h ),
.autoThrottling( false );
// Register event handlers
- registerEvent( &SomeModule::read, event );
+ registerEvent( event, &SomeModule::read );
// Register passive connector handlers
input.onRequest( &SomeModule::outputRequest );
event.enable();
}
+ void v_init() {
+ // Optional. Called after before running the module but after connections have been
+ // set up. This is either directly before senf::ppi::run() or senf::ppi::init() is
+ // called or, for modules created while the PPI is already running, after returning
+ // from all event handlers but before going back to the event loop.
+ }
+
};
\endcode
If your module only has a single input connector, you should call this connector \c
input. If it has only a single output connector, you should call it \c output. This allows
to setup connections without stating the connector explicitly (see senf::ppi::connect()).
+
+ \see \ref ppi_modules
*/
class Module
- : boost::noncopyable
+ : ModuleManager::Initializable, boost::noncopyable
{
public:
virtual ~Module();
The return value may be used to alter routing
parameters like throttling parameters.
- \param[in] source Data source, object which controls
+ \param[in] input Data source, object which controls
incoming data (connector or event)
- \param[in] target Data target, object which controls
+ \param[in] output Data target, object which controls
outgoing data (connector or event)
\returns Route instance describing this route
+ \see \ref ppi_throttling
\note The real implementation is not provided by three
overloads but by a single template member */
route(EventDescriptor & input, connector::OutputConnector & output);
///< Define flow information
/**< Route from an event to a connector. Routing from an
- event to a connector defeines the event as the
- conceptual 'source' of the data. THis means, the event
+ event to a connector defines the event as the
+ conceptual 'source' of the data. This means, the event
controls how packets are sent (Example: Routing from an
- IOEVent to an output defines, that output data will be
+ IOEvent to an output defines, that output data will be
generated whenever the event is signaled).
This event routing allows to automatically
void registerEvent(Descriptor & descriptor, Target target);
#else
template <class Target>
- void registerEvent(Target target, EventDescriptor & descriptor);
+ void registerEvent(EventDescriptor & descriptor, Target target);
///< Register an external event
/**< The \a target argument may be either an arbitrary
callable object or it may be a member function pointer
\param[in] target The handler to call whenever the
event is signaled
- \param[in] descriptor The type of event to register */
+ \param[in] descriptor The type of event to register
+ \note The real implementation has the second arguments
+ type as an additional template parameter. */
#endif
ClockService::clock_type time() const; ///< Time-stamp of the currently processing event
private:
#endif
- virtual void init(); ///< Called just before the network is run
+ virtual void v_init(); ///< Called after module setup
+ /**< This member is called directly before the PPI (resumes)
+ execution. It is called after connections have been
+ setup before entering the PPI main loop.
+
+ You may overload this member. Your overload should
+ always call the base-class implementation. */
#ifndef DOXYGEN
public: