ChangeLogTag: Wed Aug 15 12:06:20 2001 Balachandran Natarajan <bala@cs.wustl.edu>

1 files changed, 3 insertions, 34 deletions

diff --git a/TAO/tao/GIOP_Message_State.h b/TAO/tao/GIOP_Message_State.h
index 3f262373f54..594747dc4cc 100644
--- a/TAO/tao/GIOP_Message_State.h
+++ b/TAO/tao/GIOP_Message_State.h
@@ -95,6 +95,9 @@ private:
 
 private:
 
+  /// The GIOP base class..
+  TAO_GIOP_Message_Base *base_;
+
   // GIOP version information..
   TAO_GIOP_Message_Version giop_version_;
 
@@ -110,40 +113,6 @@ private:
   /// Request Id from the Fragment header
   CORBA::ULong request_id_;
 
-  /**
-   * The fragments are collected in a chain of message blocks (using
-   * the cont() field).  When the complete message is received the
-   * chain is reassembled into the main message block that is sent
-   * along
-   */
-  //  ACE_Message_Block fragmented_messages;
-
-
-  /**
-   * The byte order for the the first fragment
-   * @@ The current implementation cannot handle fragments with
-   *    different byte orders, this should not be a major problem
-   *    because:
-   *    1) It is unlikely that we are going to receive fragments.
-   *    2) The spec *seems* to allow different byte_orders, but it is
-   *       unlikely that any ORB will do that.
-   *    3) Even if we allowed that at this layer the CDR classes are
-   *       not prepared to handle that.
-   */
-  //  CORBA::Octet first_fragment_byte_order;
-
-  /// The GIOP version for the first fragment
-  /// @@ Same as above, all GIOP versions must match.
-  // TAO_GIOP_Message_Version first_fragment_giop_version;
-
-  /**
-   * If the messages are chained this represents the message type for
-   * the *complete* message (remember that the last message will be
-   * fragment and the upper level needs to know if it is a request,
-   * locate request or what).
-   */
-  // CORBA::Octet first_fragment_message_type;
-
   /// (Requests and Replys)
   CORBA::Octet more_fragments_;