On Fri, Feb 14, 2003 at 11:32:21PM -0500, Craig Rodrigues wrote:
> On Fri, Feb 14, 2003 at 11:12:58AM -0800, Guy Harris wrote:
> > Yes, but that would mean that Ethereal would, once again, report packets
> > in the capture that I'll send you (under separate cover) as malformed,
> > and would, for example, get the Request id, Response expected, and
> > Object Key length fields in the first of those packets wrong.
>
> The packet trace that you have is generating non-compliant
> GIOP.
>
> In your patch, you added:
>
> 4787 if (seqlen_cd == 0)
> 4788 continue;
> 4789
> 4790 /* Skip the byte-order octet */
> 4791 seqlen_cd -= 1;
> 4792
> 4793 if (seqlen_cd == 0)
> 4794 continue; /* what is the byte order of one hand clapping? */
> 4795
>
>
>
> Well, you can't skip the byte-order octet like that.
"Skip the byte-order octet" means "the pointer has already been advanced
past it, so we have to decrement the length of the sequence not to
include it.
It does not mean "ignore the byte order octet". Sorry about the
confusing comment; I'll update it to more clearly indicate what's being
done.
> The packet trace you provided had a Service Context ID of 1 (CodeSets).
> Section "13.7.1 Standard Service Contexts" of the CORBA 3.0.2
> standard states that CodeSets is a CDR encapsulation of the following
> of a CONV_FRAME::CodeSetContext. This structure is defined on
> page 13-45 of the CORBA 3.0.2 standard as:
>
> module CONV_FRAME {
> typedef unsigned long CodeSetId;
> struct CodeSetContext {
> CodeSetId char_data;
> CodeSetId wchar_data;
> };
> };
>
>
> The rules for CDR encapsulation are stated in
> Section "15.3.3 Encapsulation" as follows:
>
> "When encapsulating OMG IDL data types, the first
> octet in the stream (index 0) contains a boolean value indicating
> the byte ordering fo the encapsulated data.
>
> .
> .
> .
> Marshaled data are aligned relative to the beginning
> of the octet stream (the first octet of which is occupied by the
> byte order flag)."
>
> So you can't ignore the byte order flag in the CDR encoded
> buffer, because it is necessary for correctly decoding data in
> the buffer on the correct alignment boundaries. Compliant ORB's get
> this right, including TAO 1.3.
Yes, that's why there's an "Endianness: Big Endian (0)" entry under
"CodeSets" in the tree for packet 21. Open up "Code Sets" and you'll
see it, right after "Sequence Length".
"Sequence Length" is the length discussed in 15.3.3 Encapsulation of the
December 2002 3.0.2 CORBA spec:
http://www.omg.org/cgi-bin/doc?formal/02-12-02.pdf
on page 15-14 (546 in the PDF):
When the encapsulation is encoded as type sequence<octet> for
subsequent marshaling, an unsigned long value containing the
sequence length is prefixed to the octet stream, as prescribed
for sequences (see Section 15.3.2.5, ``Sequence,'' on page
15-12). The length value is not part of the encapsulation?s
octet stream, and does not affect alignment of data within the
encapsulation.
What follows is the octet stream - the "elements of the sequence", as
per 15.3.2.5.
15.3.3 says
When encapsulating OMG IDL data types, the first octet in the
stream (index 0) contains a boolean value indicating the byte
ordering of the encapsulated data. If the value is FALSE (0),
the encapsulated data is encoded in big-endian order; if TRUE
(1), the data is encoded in little-endian order, exactly like the
byte order flag in GIOP message headers (see Section 15.4.1,
``GIOP Message Header,'' on page 15-31). This value is not part
of the data being encapsulated, but is part of the octet stream
holding the encapsulation. Following the byte order flag, the
data to be encapsulated is marshaled into the buffer as defined
by CDR encoding rules. Marshaled data are aligned relative to
the beginning of the octet stream (the first octet of which is
occupied by the byte order flag).
so the next byte after, in that part of frame 21, the 00 00 00 0c that's
the Sequence Length of 12, is the "Endianness: Big Endian (0)" item.
What follows that is the data to be encapsulated.
> Your GIOP packet trace is unfortunately no good because it contains
> missing and consequently misaligned data. It is being generated
> by a non-compliant ORB product.
Eh? I don't see that, from the captured data and the CORBA spec - or
from any of the *other* captures I have (at home) that had the same
problems.
> The other thing that is wrong with your patch is that
> you do get_CDR_encap_info() *before* checking the vcsid and scid.
>
> This is wrong. Even though the OMG specified service contexts
> are CDR encapsulated, it is legal for someone to use
> a vcsid > 0 (OMG reserves vcsid ==0) and put whatever junk they
> want in the context_data field, even if it is not CDR encapsulated.
Where in the spec does it say that?
On page 13-30 (page 496 in the PDF), in 13.7 Service Context, it says:
Each Object Service requiring implicit service-specific context
to be passed through GIOP will be allocated a unique service
context ID value by OMG. Service context ID values are of type
unsigned long. Object service specifications are responsible
for describing their context information as single OMG IDL data
types, one data type associated with each service context ID.
The marshaling of Object Service data is described by the
following OMG IDL:
module IOP { // IDL
typedef unsigned long ServiceId;
struct ServiceContext {
ServiceId context_id;
sequence <octet> context_data;
};
typedef sequence <ServiceContext>ServiceContextList;
};
The context data for a particular service will be encoded as
specified for its service-specific OMG IDL definition, and that
encoded representation will be encapsulated in the context_data
member of IOP::ServiceContext. (See Section 15.3.3,
``Encapsulation'' on page 15-14). The context_id member contains
the service ID value identifying the service and data format.
Context data is encapsulated in octet sequences to permit ORBs
to handle context data without unmarshaling, and to handle
unknown context data types.
which seems to suggest that the context_data is, at minimum, a
context_data structure (otherwise, an ORB wouldn't be able to handle
unknown context data types, as it wouldn't know how long the service
context was!).