Re: SCTP API section 7.1.13

From: Randall Stewart <rrs@cisco.com>
Date: Wed Feb 16 2005 - 07:57:13 EST

('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) David Lehmann wrote:
> Randall Stewart wrote:
>
>>> 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...
>
>
> OOOhhhh... The light bulb just turned on!
>
> I remember this issue when speaking to one of the authors of RFC 3542.
> In section 11.4, it states "there is no way to pass the destination via
> getsockopt()", even though the given struct ip6_mtuinfo has a spot for
> the destination.
>
> Thinking out loud...
> Maybe there should be a generic sock_opt_info().

That maybe.. or getsockopt() needs to be re-defined to require
it to allow in-out parameters.. its that way on most
BSD's but I don't think so on most other O/S's :-D

>
> int sock_opt_info(int s, int level, int optname, void *optval, int
> *optlen);
>
> The association id can be put in each structure so it could be used
> in sock_opt_info(). Actually, the association id is in each structure.
> Why is the association id needed on sctp_opt_info()?
>

Well, in the case of the 1-to-N model, you need to figure
out which association id is being requested information
on...

>> 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
>
>
> I think you are missing a "get" after the "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().
>
>
> Got it. Maybe a statement is needed to explicitly state
> what you just wrote: "Sctp_opt_info() is a replacement
> for getsockopt() only and will not set any options associated
> with the specified socket. Setsockopt() must be used to
> set these options."
>
I have fixed the missing "get" (I noticed that to when I cut
and pasted into the email :-0)

And put in most of the wording above verbatim.. with one
minor change.. it will read:

<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>
<t>
The sctp_opt_info() call is a replacement for getsockopt() only
and will not set any options associated with the specified socket.
A setsockopt() must be used to set any writeable option.
</t>

That hopefully will cover it :-D

>> ...
>>
>>> 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.
>
>
> Yep, I did misunderstand the functionality of sctp_opt_info.
> Thanks for belaboring the point even though I didn't want to. :-)
>
> Nonetheless, I would like to see the authors discuss the
> issue of making 'spp_hbinterval == 0' do nothing on a
> setsockopt().

Maybe we can have an authors and interested folks pow-wow
at the IETF..

R

>> That definetly needs to be clearified in the next pass.
>
>
> Agreed.
>

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

Received on Wed Feb 16 08:03:26 2005