Subject: sctp_sndrcvinfo structure

From: "Anatoly Khusid" <[email-masked]>
Date: Fri, 18 Mar 2005 10:43:02 -0500

Hi,

I know there has been some discussions on whether SCTP user should populate
fields of this structure in the network byte order or not.  In particular, I
am interested in sinfo_stream filed.  When I am sending a message to SCTP,
do I need to put sinfo_stream into network byte order or not?
SCTP spec. does not mention anything about that, just wanted to be clear.
Similar question applies to other fields in this structure.

Thanks,

Anatoly

-----Original Message-----
From: Randall Stewart [mailto:[email-masked]]
Sent: Wednesday, March 16, 2005 3:20 PM
To: Vlad Yasevich
Cc: [email-masked]
Subject: Re: ABORTing 1-to-many assocs

Vlad:

Hmm.. in just taking a peek .. this is how
the KAME stack already behaves.. I.e. if you
set so_linger when you quit it will ABORT all
assoc's.

I don't see any harm in formalizing this.. do others??

R

Vlad Yasevich wrote:
> Hi
>
> I've been asked if there was a way to abort all the associations
> on a 1-to-many style socket.  The only way specified now is to send
> MSG_ABORT (changing to SCTP_ABORT).  However, the person asking
> the question had the following scenario.
>
> Suppose a service with an endpoint that has multiple associations
> should happen to crash.  The preference of this service is to
> ABORT all the clients instead of performing a shutdown sequence.
> This is currently not possible with 1-to-many API, and rewriting
> the service to use 1-to-1 style is not an option.
>
> Would it make sense to extend the SO_LINGER option to apply to
> 1-to-many style as well? It would affect all association for a given
> endpoint.  Individual associations can continue using MSG_ABORT (or
> SCTP_ABORT as it will be called).
>
> Thanks
> -vlad
>

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

---

From: Randall Stewart <[email-masked]>
Date: Fri, 18 Mar 2005 11:15:43 -0500

Anatoly:

The interface via the sctp_sndrcvinfo with the exception
of the ppid field is a local thing and thus I
would expect it to be in host byte order in
the API. On the wire, of course, the SCTP stack
should convert this to network order...

The PPID field is a exception due to the nature of
it.. aka an opaque data field.

SSID is not opaque, sctp must have an understanding
of this field..

R

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 18 Mar 2005 14:40:06 -0800

> should convert this to network order...

Yes.  I guess we also need to clarify this in the draft.

-- 

						K. Poon.
						[email-masked]