/** \file
\brief Connectors public header */
-/** \defgroup connectors Connector classes
-
- A connector has two independent properties
- \li it may be \e active or \e passive
- \li it may be an \e input or an \e output
-
- \e Active connectors are activated from within the module, \e passive connectors are signaled by
- the external framework. \e Input modules receive packets, \e output modules send packets.
-
- All passive connectors call some onRequest callback whenever I/O needs to be performed. All
- input modules possess a packet queue.
-
- We therefore have 4 connector types: senf::ppi::ActiveInput, senf::ppi::ActiveOutput,
- senf::ppi::PassiveInput and senf::ppi::PassiveOutput.
- */
-
#ifndef HH_Connectors_
#define HH_Connectors_ 1
namespace ppi {
namespace connector {
- /** \brief Connector baseclass
+ /** \namespace senf::ppi::connector
+ \brief Connector classes
+
+ A connector has two independent properties
+ \li it may be \e active or \e passive
+ \li it may be an \e input or an \e output
+
+ \e Active connectors are activated from within the module, \e passive connectors are
+ signaled by the external framework. \e Input modules receive packets, \e output modules send
+ packets.
+
+ All passive connectors call some onRequest callback whenever I/O needs to be performed. All
+ input modules possess a packet queue.
+
+ We therefore have 4 connector types: senf::ppi::ActiveInput, senf::ppi::ActiveOutput,
+ senf::ppi::PassiveInput and senf::ppi::PassiveOutput.
+ */
+
+ /** \brief Connector base-class
This connector provides access to the generic connector facilities. This includes the
connection management (access to the connected peer) and the containment management (access
friend class module::Module;
};
- /** \brief Passive connector baseclass
+ /** \brief Passive connector base-class
A passive connector is a connector which is activated externally whenever an I/O request
occurs. Passive connectors are the origin of throttling notifications. Depending on the type
private:
// Called by the routing to change the remote throttling state
- void notifyThrottle(); ///< Forward a throttling notification to this connector
- void notifyUnthrottle(); ///< Forward an unthrottling notification to this connector
+ void notifyThrottle(); ///< Forward a throttle notification to this connector
+ void notifyUnthrottle(); ///< Forward an unthrottle notification to this connector
// Internal members to emit throttling notifications
void emitThrottle();
// Called after unthrottling the connector
virtual void v_unthrottleEvent();
+ // called by ForwardingRoute to register a new route
+ void registerRoute(ForwardingRoute & route);
+
typedef detail::Callback<>::type Callback;
Callback callback_;
bool remoteThrottled_;
bool nativeThrottled_;
- friend class senf::ppi::detail::ForwardForwardingRouteImplementation;
- friend class senf::ppi::detail::BackwardForwardingRouteImplementation;
+ typedef std::vector<ForwardingRoute*> Routes;
+ Routes routes_;
+
+ friend class senf::ppi::ForwardingRoute;
};
- /** \brief Active connector baseclass
+ /** \brief Active connector base-class
An active connector is a connector which emits I/O requests. Active connectors receive
throttling notifications. Depending on the type of connector (input or output) the
\param[in] handler Handler to call on throttle
notifications. */
- void onThrottle();
+ void onThrottle(); ///< Clear throttle notification handler
template <class Handler>
void onUnthrottle(Handler handler); ///< Register unthrottle notification handler
\param[in] handle Handler to call on unthrottle
notifications. */
- void onUnthrottle();
+ void onUnthrottle(); ///< Clear unthrottle notification handler
+
+ bool throttled() const; ///< \c true, if peer() is throttled
PassiveConnector & peer() const;
friend class PassiveConnector;
};
- /** \brief Input connector baseclass
+ /** \brief Input connector base-class
An input connector receives packets. It may be either an ActiveConnector or a
PassiveConnector. An input connector contains a packet queue. This queue enables processing
insertion/removal properties on both ends.
So probably we will use a deque. I'd like a container which keeps iterators intact on
- isertion/deletion but I believe that list is just to expensive since every packet will
+ insertion/deletion but I believe that list is just to expensive since every packet will
be added to the queue before it can be processed.
*/
class InputConnector
friend class OutputConnector;
};
- /** \brief Output connector baseclass
+ /** \brief Output connector base-class
An output connector sends out packets. It may be either an ActiveConnector or a
PassiveConnector. An output connector does \e not have an built-in queueing, it relies on
ActiveOutput & peer() const;
- bool boolean_test() const;
+ bool boolean_test() const; ///< \c true, if ! empty()
template <class QDisc>
void qdisc(QDisc const & disc); ///< Change the queueing discipline
public:
ActiveInput & peer() const;
- bool boolean_test() const;
+ bool boolean_test() const; ///< Always \c true
- void connect(ActiveInput & target);
+ void connect(ActiveInput & target); ///< Internal: Use senf::ppi::connect() instead
friend class ActiveInput;
};
public:
PassiveOutput & peer() const;
- bool boolean_test() const;
+ bool boolean_test() const; ///< \c true, if ! empty() or ! throttled()
void request(); ///< request more packets without dequeuing any packet
public:
PassiveInput & peer() const;
- bool boolean_test() const;
+ bool boolean_test() const; ///< \c true if peer() is ! throttled()
- void connect(PassiveInput & target);
+ void connect(PassiveInput & target); ///< Internal: Use senf::ppi::connect() instead
};
///@}
projects / senf.git / blobdiff