RE: SCTP API section 7.1.13

From: Ryan W Bickhart <bickhart@cis.udel.edu>
Date: Tue Feb 15 2005 - 11:05:18 EST
('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) -----Original Message-----
From: David Lehmann [mailto:lehmann@ulticom.com]
Sent: Tuesday, February 15, 2005 9:26 AM
To: SCTP Implementors
Subject: Re: SCTP API section 7.1.13

> How do you "get all the current peer address parameter values" without
> setting it? The draft says that you "should" use sctp_opt_info which
> 'sets' and 'gets'. Does this mean that you can use getsockopt() as well?
> If so, I did not see that statement in the draft.

According to UNP (third ed) page 278, sctp_opt_info is a more portable
replacement for getsockopt. It says that some OS implementations may not
support in-out variables with getsockopt, which SCTP needs in some cases.
So you could think of sctp_opt_info as a glorified getsockopt that always
works. On FreeBSD, for example, you can use getsockopt directly, but this
is discouraged for portability reasons.

So you might do:
sctp_opt_info(...) /* get the settings */
/*modify what you want */
setsockopt(...) /* save the changes */

> Even if this is the case, it seems that this API is
> inconsistent with the other structures where zero means
> "don't change". Also, it is very inconvenient to get a value just
> so we can then set it to the same value.

I agree on both counts.

> IMHO, zero should mean "don't change". UINT32_MAX could mean
> disable heartbeats. (Or ~49 days, which is affectively
> disabled.) How about adding a boolean parameter "spp_send_hb"?
> zero would mean don't send a HB; nonzero would mean send it.
> That would leave spp_hbinterval to behave like the other parameters.

Even with the boolean, I think we would still have the same type of
consistency problem, just with a different parameter. How would you turn
off heartbeats by setting spp_send_hb to zero if zero means do not change
the current value? :) Maybe the first suggestion might work better...any
other ideas?

Ryan
Received on Tue Feb 15 11:12:15 2005

This archive was generated by hypermail 2.1.8 : Mon Mar 13 2006 - 15:22:24 EST