Subject: API draft: section 8.3 and 8.5

From: David Lehmann <[email-masked]>
Date: Tue, 08 Feb 2005 09:25:39 -0500

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.

-- 

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

---

From: Randall Stewart <[email-masked]>
Date: Tue, 08 Feb 2005 11:26:51 -0500

>    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

---

From: "Peter Lei (peterlei)" <[email-masked]>
Date: Tue, 08 Feb 2005 10:44:43 -0600

>    addresses returned will be IPv6 addresses and/or IPv4 mapped addresses.

It is not necessarily v4-mapped addresses that are returned (if
allowed/enabled).  The SCTP_I_WANT_MAPPED_V4_ADDRESSES option
determines what kind of v4 addresses are returned:  v4 addresses
(if "off"), or v4-mapped addresses (if "on").  See section 7.1.16.

Our BSD implementation (in KAME) supports this option.

regards,
--peter

---

From: David Lehmann <[email-masked]>
Date: Tue, 08 Feb 2005 14:12:04 -0500

> For other OS's.. aka BSD.. you CAN disable that option so you would

OK then, explain to me what the "mixed" return data is.
Are you stating that there could be sockaddr_in6 elements _and_
sockaddr_in elements returned?  i.e. I can't index into the
"array" buy rather have to move the pointer down the appropriate
number of bytes depending on the record?

e.g.
	struct sockaddr *addrs;
	int count;

	count = sctp_getpaddrs(sd, id, &addrs);

	while (count-- >= 0)
	{
		if (addrs->sa_family == AF_INET)
		{
			struct sockaddr_in *sin = (struct sockaddr_in *)addrs;

			/* Do something with returned address */
			...
		
			/* go to next addr */
			addrs = (struct sockaddr *)(sin + 1)
		}
		else if (addrs->sa_family == AF_INET6)
		{
			struct sockaddr_in6 *sin6 =
				(struct sockaddr_in6 *)addrs;

			/* Do something with returned address */
			...
		
			/* go to next addr */
			addrs = (struct sockaddr *)(sin6 + 1)
		}
		else
		{
			/* bogus family */
		}
	}

--

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 08 Feb 2005 11:46:51 -0800

> which is why it is vague...

I think this is more about programming practise.  It is better to
have an array of the same type struct than a list of mixed type struct
because of alignment issues among other things.

-- 

						K. Poon.
						[email-masked]

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 08 Feb 2005 13:05:01 -0800

> number of bytes depending on the record?

The type cast of addrs to (struct sockaddr_in *) and (struct
sockaddr_in6 *) in the following code may have problem
because of alignment issue.  So it is safer to copy from
addrs to a local sockaddr variable and use the local instead.

-- 

						K. Poon.
						[email-masked]

---

From: Randall Stewart <[email-masked]>
Date: Tue, 08 Feb 2005 17:07:37 -0500

>             addrs = (struct sockaddr *)(sin6 + 1)
Or in BSD land you can use the sa_len field.. thats what
it is for.

R

---

From: David Lehmann <[email-masked]>
Date: Tue, 08 Feb 2005 17:15:08 -0500

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

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

IMHO, the spec should expound upon the usage of these functions,
explaining its relationship with SCTP_I_WANT_MAPPED_V4_ADDR.

--

---

From: Randall Stewart <[email-masked]>
Date: Wed, 09 Feb 2005 06:33:14 -0500

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

> is on.  Otherwise, we get a list of variable-length records.

Which is the default

> explaining its relationship with SCTP_I_WANT_MAPPED_V4_ADDR.
That can be added :-D

R