Re: SCTP API section 7.1.13

From: Randall Stewart <rrs@cisco.com>
Date: Tue Feb 15 2005 - 15:31:50 EST

('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) David Lehmann wrote:
> Ryan W Bickhart wrote:
>
>>> 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
>
>
> Who is defining sctp_opt_info? UNP or SCTP API I-D?
> If it is the SCTP API I-D, then usage need to be defined clearly in the
> I-D.
>
>> 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.
>
>
> I don't necessarily agree with these statements, but I won't belabor the
> point.
>

But that IS the whole point of the sctp_opt_info.. i.e. a replacement
for getsockopt that allows in-out parameters...

I can say that with authority since I was there when all of
us authors debated the need for it.. and this was the ONLY reason
to create it...

The text currently says:
****************************************************************
<t>
   For some IP stacks getsockopt() is read-only, so a new
   interface will be needed when information must be passed both in to
   and out of the SCTP stack. The syntax for sctp_opt_info() is,
</t>
<figure>
<artwork>
int sctp_opt_info(int sd,
                   sctp_assoc_t id,
                   int opt,
                   void *arg,
                   socklen_t *size);
</artwork>
</figure>
<t>
     For one-to-many style sockets, id specifies the association to
query. For
     one-to-one style sockets, id is ignored.
</t>
<t>
     opt specifies which SCTP socket option to get. It can
     any socket option currently supported that requests information
     (either read/write options or read only) such as:
</t>
*******************************************************

You may be being confusred by that last line in ()'s

What that is eluding to is the "classification" of the socket
options.. i.e. the document classify's all options as read-only,
or read-write options... This is NOT saying anything about
sctp_opt_info being used to set an option..

And I think that first bit clearly states this is as Ryan
implied.. due to some O/S's not allowing in/out in a
getsockopt().

>> So you might do:
>> sctp_opt_info(...) /* get the settings */
>
>
> My understanding is that sctp_opt_info will _set_ the values.
> How do you get the values before setting them?

No.. its used for read only .. but with an in parameter.
>
>> /*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.
>
>
> Progress! :-)
>
>>> 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?
>
>
> I was suggesting this:
> struct sctp_paddrparams {
> sctp_assoc_t spp_assoc_id;
> struct sockaddr_storage spp_address;
> uint32_t spp_hbinterval;
> uint16_t spp_pathmaxrxt;
> uint8_t spp_send_hb;
> };
>
> If spp_hbinterval == 0, do not change the HB interval.
> If spp_hbinterval != 0, set the HB interval to the given number
> of milliseconds. Setting it to UINT32_MAX would disable
> the HBs. (My point above is that if the SCTP implementation did not
> make a special case for UINT32_MAX, the interval would be
> more than 49 days, which effectively disables it.)
>
> If spp_pathmaxrxt == 0, do not change the path max retrans.
> If spp_pathmaxrxt != 0, set the path max retrans to that value.
>
> If spp_send_hb == 0, do not send a HB.
> If spp_send_hb != 0, send a HB. (spp_hbinterval should not
> cause the immediate sending of a HB.)
>
> Better yet, leave the sctp_paddrparams as it was and create
> a new function to send a HB:
>
> int sctp_send_heartbeat(
> int sd, sctp_assoc_t id, const struct sockaddr *addr);
>
>

I can live with either approach... but I think the heart of
this problem is that you are assuming that sctp_opt_info() is
a write option.. it is NOT meant to change any values.

That definetly needs to be clearified in the next pass.

R

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

Received on Tue Feb 15 15:36:21 2005