Stack selection by application-id (configurable), and minor fixes

[anna.git] / include / anna / diameter / codec / Message.hpp

diff --git a/include/anna/diameter/codec/Message.hpp b/include/anna/diameter/codec/Message.hpp
index 2b65175..c8dab7c 100644 (file)
--- a/include/anna/diameter/codec/Message.hpp
+++ b/include/anna/diameter/codec/Message.hpp
@@ -280,10 +280,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