Re: SCTP API section 7.1.13

From: David Lehmann <lehmann@ulticom.com>
Date: Tue Feb 15 2005 - 16:49:32 EST

('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) 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().

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()?

> 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 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().

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

Agreed.

-- 
David Lehmann                          Ulticom, Inc.
AOL/Yahoo IM: davidULCM                1020 Briggs Road
1-856-787-2729                         Mt. Laurel, NJ 08054   USA

Received on Tue Feb 15 17:14:36 2005