Re: SCTP API section 5.2.2

From: Randall Stewart <rrs@cisco.com>
Date: Tue Mar 01 2005 - 16:54:51 EST

('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) David Lehmann wrote:
> Kacheong Poon wrote:
>
>> David Lehmann wrote:
>>
>>> That was a lot of words just to state that it is in network byte
>>> order. For a couple fields, the draft does explicitly says that
>>> the values are in "network byte order."
>>
>>
>> Actually, even though the sinfo_ppid is "supposed" to be
>> a 32 bit integer, it is really opaque to the SCTP stack and
>> socket layer. So the app may as well put 4 8 bit bytes
>> there. Specifying any byte order in the text is probably
>> not correct. This also applies to the sinfo_context.
>
>
> I think that I would have to disagree. This is a 32-bit value
> which is sent over the network and read by the peer SCTP user.
> The payload protocol has to be interpreted by the upper layer.
> There is nothing in RFC 2960 that makes this field different
> from any other field (e.g. the stream number, SSN, etc) in
> this regard.

The word opaque in the spec does make it different.
Data is also opaque.. do you want the SCTP stack
playing around with what it "thinks" are int's..

You don't. And I do agree with Kacheong completely here.. an
app can in theory put 4 8 bit values or 2 16 bit values or
whatever it chooses to do with the field...

You can't say what byte order they are in since the user
can do a ntohl() on them or NOT .. and so it is opaque as
the original text in 2960 said...

>
> In addition, when Sigtran protocols define the payload
> protocol ID, they just specify the number. (e.g. 2 for
> M2UA. See RFC 3331, section 8.1. M2UA doesn't specify
> which of the four bytes should be set to 2.)

Well.. then they need to specify that its a 2 in
network byte order...

> The sinfo_context, OTOH, should be opaque. It is passed
> by the user to SCTP, which may send it back to the _same_ user.
> The sinfo_context does not get sent over the network.
> Since the user that is interpreting the sinfo_context
> value is the _same_ user that created the value, it makes
> sense that it is opaque.
Opaque is opaque.. the SCTP stack will place the data
in the packet in PPID terms and NOT touch it.. the same
with the data on the wire... the stack may bust it up
into chunks and re-assemble it .. but it will not touch
in bytes to change the "byte order".

and the context field will of course be opaque as well.. its
less likely to have a byte order issue though.. since as you
say, it remains on the same machine...

R

>
>>> IMHO, the draft should be explicit for all fields. Maybe for each
>>> structure, the draft should state something like:
>>> "All members of struct sctp_xxxx are in network byte order,
>>> except for member3 and member6, which are in host byte order."
>
>
> I still think the above clarification should be made for each
> structure.
>

-- 
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222

Received on Tue Mar 1 17:00:06 2005