Re: SCTP API section 5.2.2

From: Michael Tuexen <Michael.Tuexen@micmac.franken.de>
Date: Tue Mar 01 2005 - 04:18:03 EST

('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) Hi David,

see my comments in-line.

Best regards
Michael

On Feb 28, 2005, at 22:14 Uhr, David Lehmann wrote:

> Hello,
>
> In section 5.2.2, the I-D states:
> sinfo_ppid: 32 bits (unsigned integer)
>
> This value in sendmsg() is an opaque unsigned value that is passed
> to
> the remote end in each user message. In recvmsg() this value is the
> same information that was passed by the upper layer in the peer
> application. Please note that byte order issues are NOT accounted
> for and this information is passed opaquely by the SCTP stack from
> one end to the other.
This means that the user has to do the htonl() call before the send call
and ntohl() call after the receive call. It is NOT done by the
SCTP-implementation.
>
> The last sentence concerns me. Is this stating that the ppid will
> not be sent up to the user in host byte order? As stated, it sounds
> like that if I have a server which examines the ppid, I will get a
> different value depending if the application sent the data from an
> Intel box as opposed to a Sparc box.
The SCTP user must provide it in network byte order and receiver
must expect it in network byte order.
>
> If the last sentence was trying to say that the ppid will be passed up
> in network byte order, can it be reworded to plainly say so?
>
>
> --
>
> David Lehmann
> Ulticom, Inc.
> http://www.ulticom.com
Received on Tue Mar 1 05:00:40 2005