Re: API draft: section 8.3 and 8.5

From: Randall Stewart <rrs@cisco.com>
Date: Tue Feb 08 2005 - 11:26:51 EST
('binary' encoding is not supported, stored as-is) ('binary' encoding is not supported, stored as-is) 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...

For some O/S's (such as Kacheongs) you cannto turn
SCTP_I_WANT_MAPPED_V4_ADDR
Off... and thats fine.. then your statements above would be completely
true..

For other OS's.. aka BSD.. you CAN disable that option so you would
get back a mix..

R

-- 
Randall Stewart
ITD
803-345-0369 <or> 815-342-5222
Received on Tue Feb 8 11:30:59 2005

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