-// ANNA - Anna is Not Nothingness Anymore
-//
-// (c) Copyright 2005-2014 Eduardo Ramos Testillano & Francisco Ruiz Rayo
-//
-// http://redmine.teslayout.com/projects/anna-suite
-//
-// Redistribution and use in source and binary forms, with or without
-// modification, are permitted provided that the following conditions
-// are met:
-//
-// * Redistributions of source code must retain the above copyright
-// notice, this list of conditions and the following disclaimer.
-// * Redistributions in binary form must reproduce the above
-// copyright notice, this list of conditions and the following disclaimer
-// in the documentation and/or other materials provided with the
-// distribution.
-// * Neither the name of the copyright holder nor the names of its
-// contributors may be used to endorse or promote products derived from
-// this software without specific prior written permission.
-//
-// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
-// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
-// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
-// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
-// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
-// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
-// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
-// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
-// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
-// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-//
-// Authors: eduardo.ramos.testillano@gmail.com
-// cisco.tierra@gmail.com
+// ANNA - Anna is Not Nothingness Anymore //
+// //
+// (c) Copyright 2005-2015 Eduardo Ramos Testillano & Francisco Ruiz Rayo //
+// //
+// See project site at http://redmine.teslayout.com/projects/anna-suite //
+// See accompanying file LICENSE or copy at http://www.teslayout.com/projects/public/anna.LICENSE //
#ifndef anna_diameter_codec_Message_hpp
const anna::diameter::stack::Command *getStackCommand(CommandId id) const throw(anna::RuntimeException);
void setFailedAvp(const parent_t &parent, AvpId wrong, const char *wrongName = NULL) throw(anna::RuntimeException);
- // During message decoding and validation, the first wrong avp is stored and all the tracking is managed to find out its
- // nested path for the case of grouped avps with wrong avps inside. Remember the RFC 6733, section 7.5:
- //
- // In the case where the offending AVP is embedded within a Grouped AVP,
- // the Failed-AVP MAY contain the grouped AVP, which in turn contains
- // the single offending AVP. The same method MAY be employed if the
- // grouped AVP itself is embedded in yet another grouped AVP and so on.
- // In this case, the Failed-AVP MAY contain the grouped AVP hierarchy up
- // to the single offending AVP. This enables the recipient to detect
- // the location of the offending AVP when embedded in a group.
- //
- // The first wrong avp found will set the final result code, as the RFC recommends:
- //
- // The value of the Result-Code AVP will provide information on the reason
- // for the Failed-AVP AVP. A Diameter answer message SHOULD contain an
- // instance of the Failed-AVP AVP that corresponds to the error
- // indicated by the Result-Code AVP. For practical purposes, this
- // Failed-AVP would typically refer to the first AVP processing error
- // that a Diameter node encounters.
- //
- // The message keeps the list (reverse order) of avps hierarchy (in case of grouping) for the final Failed-AVP construction,
- // which is done at the end of decoding or validation, and only the first wrong avp is stored with its corresponding path.
+ // During message decoding and validation, the first wrong avp is stored and all the tracking is managed to find out its
+ // nested path for the case of grouped avps with wrong avps inside. Remember the RFC 6733, section 7.5:
+ //
+ // In the case where the offending AVP is embedded within a Grouped AVP,
+ // the Failed-AVP MAY contain the grouped AVP, which in turn contains
+ // the single offending AVP. The same method MAY be employed if the
+ // grouped AVP itself is embedded in yet another grouped AVP and so on.
+ // In this case, the Failed-AVP MAY contain the grouped AVP hierarchy up
+ // to the single offending AVP. This enables the recipient to detect
+ // the location of the offending AVP when embedded in a group.
+ //
+ // The first wrong avp found will set the final result code, as the RFC recommends:
+ //
+ // The value of the Result-Code AVP will provide information on the reason
+ // for the Failed-AVP AVP. A Diameter answer message SHOULD contain an
+ // instance of the Failed-AVP AVP that corresponds to the error
+ // indicated by the Result-Code AVP. For practical purposes, this
+ // Failed-AVP would typically refer to the first AVP processing error
+ // that a Diameter node encounters.
+ //
+ // The message keeps the list (reverse order) of avps hierarchy (in case of grouping) for the final Failed-AVP construction,
+ // which is done at the end of decoding or validation, and only the first wrong avp is stored with its corresponding path.
protected:
void setPotentiallyReTransmittedMessageBit(bool activate = true) throw() { if(activate) a_flags |= TBitMask; else a_flags &= (~TBitMask); }
/**
- Sets the message application id
+ Sets the message application id.
+
+ The codec engine could be configured to force a stack selection based in this field value: see #selectStackWithApplicationId.
+ In multistack applications (which also shall be monothreaded), you only have to take care about how to apply this method: the thing
+ is that you must not interleave message builds which belongs to different stacks. For example, you could think about setting the
+ message header for message A using stack A. Then, start to add the message header fields for a second message B using another stack B.
+ Following you would add the message A avps, but then, the stack is not going to be automatically changed (this is only done through this
+ method). The result could be unexpected when adding/encoding messages with a dictionary which does not correspond.
+
+ @warning do not interleave build/encode operations between different messages which uses different stacks over the same codec engine.
+ It seems common sense, but it is not bad to advice about this.
+
@param aid Application-id.
*/
- void setApplicationId(U32 aid) throw() { a_applicationId = aid; }
+ void setApplicationId(U32 aid) throw();
/**
Sets the message hop-by-hop
projects / anna.git / blobdiff