* may occur. If you add elements (vendors, avps, messages) is not a problem.
*
* IMPORTANT NOTES:
- * 1) if you want to reuse the message, as a recommendation, you should set engine to
- * NULL or use #clear. In that way, next operation will adjust automatically the needed
- * engine because it would not be configured in such stage.
- * 2) if you want to pre-configure the engine you will need to set the engine to NULL
- * previously and then you could change to the new one without warning/ignoring.
- * 3) if you have dedicated message objects for each interface (application id), then
+ * 1) if you want to reuse the message, as a recommendation, you should #clear the
+ * message. In that way, next operation will adjust automatically the needed engine.
+ * 2) if you have dedicated message objects for each interface (application id), then
* you could set the corresponding engine on constructor (or setEngine), and forget
* about #clear. The needed cleanup will be done automatically from decoding and xml
* loading procedures, and initialized engine will be kept along message operations.
/**
* Destructor
*/
- ~Message();
+ virtual ~Message();
+
// Virtual destructors are useful when you can delete an instance of a derived class through a pointer to base class:
// This destructor is not virtual, then a pointer to base class (even pointing to a children one) will invoke this destructor, not the derived one.
// My current solution: virtualizing method 'clear'
message is valid against all odds then validation will go on). In case that validation is enabled (codec::Engine::ValidationMode) an exception will be launched
in a moment which depends on validation depth (codec::Engine::ValidationDepth).
+ You could decode multiple times over the same object. A basic cleanup is done respecting the codec engine.
+
@param db buffer data block processed. Before decoding, the whole message instance will be cleared (no need to invoke #clear before #decode).
@param ptrAnswer Answer set by application (could be empty or not), who is responsible for its memory reservation,
and automatically built regarding standard. If message analyzed realizes to be an answer, internal reference becomes
/**
Interpret xml data in order to dump over the class content.
+ You could apply this multiple times over the same object. A basic cleanup is done respecting the codec engine.
\param messageNode Message root node obtained from @functions::xmlFileTo
*/
void fromXML(const anna::xml::Node* messageNode) throw(anna::RuntimeException);
/**
* Interpret a xml file in order to create a diameter message
+ * You could apply this multiple times over the same object. A basic cleanup is done respecting the codec engine.
*
* @see functions::messageXmlDocumentFromXmlFile
* @see fromXML
*
* @param xmlPathFile Complete path file to the xml document which represents the diameter message
*/
- void loadXML(const std::string &xmlPathFile) throw(anna::RuntimeException);
+ void loadXMLFile(const std::string &xmlPathFile) throw(anna::RuntimeException);
+
+ /**
+ * Interpret a xml string in order to create a diameter message
+ * You could apply this multiple times over the same object. A basic cleanup is done respecting the codec engine.
+ *
+ * @see functions::messageXmlDocumentFromXmlString
+ * @see fromXML
+ *
+ * @param xmlString xml representation of the diameter message
+ */
+ void loadXMLString(const std::string &xmlString) throw(anna::RuntimeException);
// getters
for example, the pattern '<avp name="Framed-IP-Address" hex-data="0a[A-Fa-f0-9][A-Fa-f0-9]0a0a"/>'
matchs IP addresses for '10.x.10.10' where x = [0..255].
- Note that string pattern could also be generated via #loadXML and then #asXML, that is to say, you
+ Note that string pattern could also be generated via #loadXMLFile/#loadXMLString and then #asXML, thus, you
could get patterns through xml files which act as conditional triggers over message. In that case,
it is not possible to specify regular expressions within xml 'hex-data' fields because parser will fail
during hexadecimal read. Normally only printable 'data' fields are used for matching issues.
For example, imagine a 'pattern.xml' file like:
- <message version="1" name="Credit-Control-Request" application-id="16777236" hop-by-hop-id="0" end-by-end-id="0">
+ <message version="1" name="Credit-Control-Request" application-id="16777236" hop-by-hop-id="0" end-to-end-id="0">
<avp name="Subscription-Id">
<avp name="Subscription-Id-Type" data="0" alias="END_USER_E164"/>
<avp name="Subscription-Id-Data" data="616[0-9]{6,6}"/>
Then you could do:
anna::diameter::codec::Message patternMessage;
- patternMessage.loadXML("pattern.xml");
+ patternMessage.loadXMLFile("pattern.xml");
std::string pattern = patternMessage.getAvp("Subscription-Id")->getAvp("Subscription-Id-Type")->asXMLString();
// Former is '<avp name="Subscription-Id-Data" data="616[0-9]{6,6}"/>'
bool match = incomingMessage.isLike(pattern);
#endif
+
projects / anna.git / blobdiff