ANNA Suite
2020b
Multipurpose development suite for Telco applications
|
#include <EngineImpl.hpp>
Classes | |
struct | FixMode |
struct | ValidationDepth |
struct | ValidationMode |
Public Member Functions | |
Avp * | createAvp (const AvpId *id) noexcept(false) |
Message * | createMessage (const CommandId *id) noexcept(false) |
EngineImpl (const char *className, const stack::Dictionary *dictionary) | |
virtual | ~EngineImpl () |
const stack::Dictionary * | getDictionary () const |
void | setValidationDepth (const ValidationDepth::_v validationDepth) |
ValidationDepth::_v | getValidationDepth () const |
void | ignoreFlagsOnValidation (bool ignoreFlags) |
bool | ignoreFlagsOnValidation () const |
void | setValidationMode (const ValidationMode::_v validationMode) |
ValidationMode::_v | getValidationMode () const |
void | setFixMode (const FixMode::_v fixMode) |
FixMode::_v | getFixMode () const |
void | setSingleFailedAVP (bool single=true) |
bool | getSingleFailedAVP () const |
Avp * | createAvp (AvpId id) noexcept(false) |
Avp * | createAvp () noexcept(false) |
Message * | createMessage (CommandId id) noexcept(false) |
Message * | createMessage () noexcept(false) |
Message * | createMessage (const std::string &xmlPathFile_or_string, bool pathfile_or_string=true) noexcept(false) |
virtual void | releaseAvp (Avp *)=0 |
virtual void | releaseMessage (Message *)=0 |
virtual std::string | asString (void) const |
virtual anna::xml::Node * | asXML (anna::xml::Node *parent) const |
AvpId | avpIdForName (const char *name) noexcept(false) |
CommandId | commandIdForName (const char *name) noexcept(false) |
Public Member Functions inherited from anna::Component | |
virtual | ~Component () |
const char * | getClassName () const |
Public Member Functions inherited from anna::Mutex | |
Mutex (const Mode::_v mode=Mode::Recursive) | |
virtual | ~Mutex () |
virtual void | lock () noexcept(false) |
virtual void | unlock () |
bool | trylock () noexcept(false) |
operator const pthread_mutex_t * () const | |
Protected Member Functions | |
virtual Avp * | allocateAvp ()=0 |
virtual Message * | allocateMessage ()=0 |
void | validationAnomaly (const std::string &description) const noexcept(false) |
Protected Member Functions inherited from anna::Component | |
Component (const char *className) | |
Component (const Component &other) | |
Protected Member Functions inherited from anna::Safe | |
Safe () | |
Additional Inherited Members | |
Protected Attributes inherited from anna::Component | |
const std::string | a_className |
General component implementation of a diameter elements factory (messages, avps) and common resources which configure encode/decode operations behaviour.
Standard inheritance is done over codec::Engine, allocating basic Avp and Message classes. A child implementation could manage complex Avp classes with new data-part formats. Grouped ones could allocate new complex Avps through such engine which knows how to allocate this special Avp's (also for complex Message classes with application-specific setters and getters as credit-control related avps, or some another context items). For example tme::Avp and tme::Message classes support three new Avp formats: ISDNNumber, ISDNAddress and Unsigned16. Anyway, main Message/Avp and Engine classes stand for all contexts included in anna::diameter, that is to say, whole contexts (at the time only TME) will be included in future when needed apart from the independent namespace version. Thank to this, single threaded applications could use whole engine in a easy way.
An engine component is associated to a single diameter stack. It is application responsability to use message container initialized with the correct codec engine depending on the context. There are helpers to do this at anna::diameter::codec::functions::getApplicationId (from xml document or hexadecimal buffer).
It is recommended to use Message class to create Avps (adding them through pair identification <code + vendor-id> prototype), but we could create Avps separately (other program section, i.e) and join them after:
1. Recommended way:
// Message creation: Message * msg = new Message(helpers::base::COMMANDID__Re_Auth_Answer, codecEngine); // Adding + creation: Avp * avp_sid = msg->addAvp(helpers::base::AVPID__Session_Id); Avp * avp_oh = msg->addAvp(helpers::base::AVPID__Origin_Host); Avp * avp_or = msg->addAvp(helpers::base::AVPID__Origin_Realm); Avp * avp_rc = msg->addAvp(helpers::base::AVPID__Result_Code); // Setting data: avp_sid->getUTF8String()->setValue("grump.example.com:33041;23432;893;0AF3B81"); ...
2. External Avp creation:
// Message creation: Message * msg = new Message(helpers::base::COMMANDID__Re_Auth_Answer, codecEngine); // Creation: Avp * avp_sid = new Avp(helpers::base::AVPID__Session_Id, codecEngine); Avp * avp_oh = new Avp(helpers::base::AVPID__Origin_Host, codecEngine); Avp * avp_or = new Avp(helpers::base::AVPID__Origin_Realm, codecEngine); Avp * avp_rc = new Avp(helpers::base::AVPID__Result_Code, codecEngine); // Adding: msg->addAvp(avp_sid); msg->addAvp(avp_oh); msg->addAvp(avp_or); msg->addAvp(avp_rc); // Setting data: avp_sid->getUTF8String()->setValue("grump.example.com:33041;23432;893;0AF3B81"); ...
The main difference is that Avps created through Message (or through grouped Avps) are internally allocated through engine which normally implements a recycler to optimize memory use.
Implementation example:
anna::diameter::codec::EngineImpl::EngineImpl | ( | const char * | className, |
const stack::Dictionary * | dictionary | ||
) |
Constructor
className | Logical name for the class. |
dictionary | Diameter dictionary. At single threaded processes, the same codec engine could be used with different diameter dictionaries (multi-stack applications). In that case the process must switch the stack for the whole decoding or enconding operation over a Message depending on the context (normally the message header Application-Id is used as stack identifier). But the smart way implies inherit from this engine creating a component for each diameter stack managed in the application. Inheritance is mandatory in multi-threaded processes: one engine, a unique stack. |
|
protectedpure virtual |
Avp allocator method.
It is recommended to use anna::Recycler for Avps creation/releasing.
Implemented in anna::diameter::codec::Engine.
|
protectedpure virtual |
Message allocator method.
It is recommended to use anna::Recycler for Message creation/releasing.
Implemented in anna::diameter::codec::Engine.
|
virtual |
|
virtual |
Class XML representation.
parent | XML node over which we will put instance information. |
Reimplemented from anna::Component.
|
noexcept |
|
noexcept |
Gets the Command identifier providing its logical name at engine dictionary
name | Name of the Command at engine dictionary |
Creates a new diameter avp assigning its identifier, using engine resources to allocate memory (recommended recycler allocation at engine component re-implementation of allocator methods). Obviously, normal objects creation (new) is possible.
id | Avp identifier. AVP flags will be established based on active dictionary for known avps, or uninitialized for unknown ones. |
|
inlinenoexcept |
Creates a new diameter avp, using engine resources to allocate memory (recommended recycler allocation at engine component re-implementation of allocator methods). Obviously, normal objects creation (new) is possible.
Creates a new diameter Message assigning its identifier, using engine resources to allocate memory (recommended recycler allocation at engine component re-implementation of allocator methods). Obviously, normal objects creation (new) is possible.
id | Command identifier. Message flags will be established based on active dictionary for known commands, or uninitialized for unknown ones. |
|
inlinenoexcept |
Creates a new diameter message, using engine resources to allocate memory (recommended recycler allocation at engine component re-implementation of allocator methods). Obviously, normal objects creation (new) is possible.
|
noexcept |
Loads an xml file/string representing a diameter message base in a DTD document (#getDTD)
xmlPathFile_or_string | Complete path file or string representation for the xml document which represents the diameter message |
pathfile_or_string | boolean about the interpretation of the previous argument |
|
inline |
|
inline |
|
inline |
|
inline |
Returns behaviour on on validation procedure. For practical purposes, the Failed-AVP would typically refer to the first AVP processing error that a Diameter node encounters (decoding error or validation error in this case). A complete validation depth incurs on multiple-content Failed-AVP and is perhaps useful during integration tasks.
|
inline |
|
inline |
Sets behaviour on validation procedure regarding stack flags. Actually, only AVP flags M & P are affected. The vendor bit is too important to be ignored, and there is no way to check operation flags (as request bit). By default (at engine start), flags are verified.
ignoreFlags | Validation will ignore flags. |
|
inline |
Gets behaviour on validation procedure regarding stack flags. Actually, only AVP flags M & P are affected. The vendor bit is too important to be ignored, and there is no way to check operation flags (as request bit). By default (at engine start), flags are verified.
|
pure virtual |
|
pure virtual |
|
inline |
|
inline |
Sets single FailedAVP. True by default. If false, and more than one wrong avp are found during message decoding and or validation, a new Failed-AVP will be added to the dynamic answer provided. The standard talks about only one but it is open to do this.
single | Single Failed-AVP boolean. |
|
inline |
|
inline |
|
protectednoexcept |
Manages warning trace or exception on validation anomaly depending on ValidationDepth configuration ('complete' and 'first error' reports respectively).
Anomaly description used in trace or exception