X-Git-Url: https://git.teslayout.com/public/public/public/?a=blobdiff_plain;f=include%2Fanna%2Fdiameter%2Fcodec%2FMessage.hpp;h=fd44c4276015318739791910fa357410dacabd7e;hb=3d71e5185fa9c93bde7363a668aecf96240ae2e9;hp=87e1012c3d343dd344e152679ef03885c10a4414;hpb=08bdffbddf4bc0938eadec51af88de18734beda3;p=anna.git diff --git a/include/anna/diameter/codec/Message.hpp b/include/anna/diameter/codec/Message.hpp index 87e1012..fd44c42 100644 --- a/include/anna/diameter/codec/Message.hpp +++ b/include/anna/diameter/codec/Message.hpp @@ -1,37 +1,9 @@ -// 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 @@ -148,28 +120,28 @@ class Message { 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: @@ -280,10 +252,21 @@ public: 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 @@ -750,7 +733,7 @@ public: std::string asXMLString() const throw(); /** - Comparison operator + Comparison operator by mean serialization @param m1 Instance 1 for Message class @param m2 Instance 2 for Message class