Subject: [Tsvwg] SCTP socket API - byte order documentation

From: Mark Butler <[email-masked]>
Date: Fri, 03 Mar 2006 01:16:43 -0700

One last thing - the current draft should have information included for 
all of the structure fields that are in network order instead of host 
order.  I understand sinfo_ppid should be specified in network order 
(right?) and believe there may be a few others (perhaps error codes and 
adaptation codes).    Surely sinfo_stream is in host order(?).   If 
these are not standardized it will be difficult to write portable code, 
and surely the purpose of the draft in the first place is to make that 
possible.

 - Mark

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Fri, 03 Mar 2006 05:07:12 -0500

> and surely the purpose of the draft in the first place is to make that 
Let me see if I understand your notion correclty.. by using
the ppid... which sctp treats opaquely.

If I want to send one without worry about byte order issues I do

sinfo->sinfo_ppid = htonl(my_ppid);

and then send down the sinfo structure.

The stream id, however is NOT sent down in network byte
order.. since its a directive to the stack which must use it.

So I do:

sinfo->sinfo_stream = 1;

To get a send in stream 1.

So, if I read you correctly.. you want any field that must be
htonl() before sending to the stack to be documented as such..

Do I read you correctly... and if so .. I agree.. good idea :-D

R

-- 
Randall Stewart
ITD - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 3 Mar 2006 12:36:10 +0100

Hi Mark,

see my comments in-line.

Best regards
Michael

On Mar 3, 2006, at 9:16 Uhr, Mark Butler wrote:

>
> One last thing - the current draft should have information included 
> for all of the structure fields that are in network order instead of 
> host order.  I understand sinfo_ppid should be specified in
I think the host byte order is default. All exceptions are mentioned, 
for example the sinfo_ppid
which is untouched by the stack and this is mentioned.
> network order (right?) and believe there may be a few others (perhaps 
> error codes and adaptation codes).    Surely sinfo_stream is in host 
> order(?).   If these are not standardized it will be
Yes, it is. Maybe it is worth writing a statement in the doc, that all 
fields are in
host byte order, except those where it is explicitly mentioned.
> difficult to write portable code, and surely the purpose of the draft 
> in the first place is to make that possible.
It should be clear which byte order is used.

---

From: Mark Butler <[email-masked]>
Date: Fri, 03 Mar 2006 19:32:53 -0700

> which is untouched by the stack and this is mentioned.

That is good to hear.  I should have double checked the draft first.

If the network order of a scalar attribute is unconverted in the API, 
there should definitely be explicit documentation that the value is 
*not* a host scalar.   The Linux kernel has special types for this 
purpose (__be16 __be32, __le16, __le32) that not only tag the byte 
order, but use a gcc extension "__attribute((bitwise))__" to raise an 
error when an incorrect assignment is done. 

Perhaps we should adopt the types be16_t and be32_t for these kind of 
fields to make the API more explicit.

 - Mark

---

From: Mark Butler <[email-masked]>
Date: Fri, 03 Mar 2006 19:36:24 -0700

> Do I read you correctly... and if so .. I agree.. good idea :-D

Yes.  I understand all of the current ones are.  I think a statement 
that all fields are in host order unless otherwise documented should be 
added as well.

- Mark