('binary' encoding is not supported, stored as-is)
('binary' encoding is not supported, stored as-is)
David Lehmann wrote:
> Randall Stewart wrote:
>
>> David Lehmann wrote:
>>
>>> Hello,
>>>
>>> Sections 8.3 and 8.5 are not clear on exactly what structures are being
>>> returned. It states:
>>> On return, addrs will point to a dynamically allocated array of
>>> sockaddr structures of the appropriate type for the socket type. The
>>> caller should use sctp_freeladdrs() to free the memory. Note that
>>> the in/out parameter addrs must not be NULL.
>>>
>>> If sd is an IPv4 socket, the addresses returned will be all IPv4
>>> addresses. If sd is an IPv6 socket, the addresses returned can be a
>>> mix of IPv4 or IPv6 addresses.
>>>
>>> IMHO, something similar to the following would be more explicit:
>>> On return, addrs will point to a dynamically allocated array of
>>> sockaddr structures of the appropriate type for the socket type.
>>> If sd is an IPv4 socket, 'addrs' will point to an array of struct
>>> sockaddr_in
>>> and the addresses returned will be all IPv4 addresses. If sd is an
>>> IPv6 socket, 'addrs' will point to an array of struct sockaddr_in6
>>> and the
>>> addresses returned will be IPv6 addresses and/or IPv4 mapped
>>> addresses.
>>>
>>> The caller should use sctp_freeladdrs() to free the memory. Note
>>> that
>>> the in/out parameter 'addrs' must not be NULL.
>>>
>>>
>> Except that if an implementation supports the
>> SCTP_I_WANT_MAPPED_V4_ADDR
>>
>> And this is turned OFF
>>
>> Then you would get a mix of V4 and V6 addresses (what Kacheong hates)..
>> which is why it is vague...
>
>
> Given Randall's and Kacheong's confirmation of what "mix" means, I think
> that I would have to side with Kacheong on this. It is not elegant
> (the user has to decode a block of variable length records) and is
> dangerous (considering the alignment issues).
And that is why there is a socket option to turn it
on and off.. You must change the socket option to
get this behavior.
>
> ..not that my opinion matters much, especially this late in the game.
> So I will spare the group the rehashing the argument. :-)
>
> Nonetheless, the spec should not be vague. On the contrary, given the
> confusing nature of the returned data, the spec should be very clear.
> Refering to the returned data as an "array" is a misnomer.
> Arrays in C refer to a list of fixed-length records/data-types.
> Arrays can be index with an integer through array subscripting.
> It seems that we only get an array when SCTP_I_WANT_MAPPED_V4_ADDR
> is on. Otherwise, we get a list of variable-length records.
>
Which is the default
> IMHO, the spec should expound upon the usage of these functions,
> explaining its relationship with SCTP_I_WANT_MAPPED_V4_ADDR.
>
That can be added :-D
R
--
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222
Received on Wed Feb 9 06:38:17 2005