Subject: RE: API suggestion

From: Richard Draves <[email-masked]>
Date: Mon, 17 Jan 2000 06:37:44 -0800

Reviving this old thread...

I was suggesting exactly the kind of union that itojun gives below. The idea
was that it would be useful to have it in standard header files instead of
having different applications inventing different versions of it.

The struct/union would be not used by any of the APIs. It would be used by
applications instead of sockaddr_storage, when those apps only care about
supporting IPv4 and IPv6.

And for these apps, it would similarly be useful to have a flag for
getaddrinfo to say that only IPv4 and IPv6 addresses are requested, if there
are none then the call should fail. I don't like the suggestion of calling
getaddrinfo twice, it's a lot more cumbersome and less efficient (probably
initiating two DNS lookups on the wire). Asking for all addresses and then
scanning through them to throw out non-IP addresses is also more cumbersome
for the app.

This suggested addition to the API is certainly not critical, but I do think
it would make porting a class of apps easier.

Rich

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, December 21, 1999 5:06 PM
> To: Richard Draves
> Cc: 'IPng List'
> Subject: Re: API suggestion 
> 
> 
> 
> >I was using sockaddr_storage variables that were holding 
> either AF_INET or
> >AF_INET6 addresses and I wanted to fetch/store the port 
> field. So my choices
> >were
> >a) look at the family and cast to the right structure -> 
> unnecessary code
> >b) just cast to sockaddr_in without looking at family -> unpleasant
> >assumptions
> 
> 	first of all you sholud not assume AF_INET or AF_INET6 
> in the above....
> 	you should check family every time you make use of the 
> sockaddr_storage.
> 
> 	You can always define a union like:
> 
> 	union sockaddr_union {
> 		struct sockaddr sa;
> 		struct sockaddr_in sin;
> 		struct sockaddr_in6 sin6;
> 	};
> 
> 	or, if port field is known to be on the same offset on 
> your system:
> 
> 	union sockaddr_union {
> 		struct {
> 			u_int8_t _len;
> 			u_int8_t _family;
> 			u_int16_t _port;
> 		} _su;
> #define su_port _su._port
> 		struct sockaddr sa;
> 		struct sockaddr_in sin;
> 		struct sockaddr_in6 sin6;
> 	};
> 
> 	to avoid casting.
> 
> >I would have been happier using sockaddr_ip variables where 
> I could directly
> >access the port field without casting.
> 
> 	which API should return this structure, or which 
> structure will convert
> 	normal sockaddr_{in,in6} to sockaddr_ip?
> 
> itojun
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Mon, 17 Jan 2000 23:41:56 +0900

>scanning through them to throw out non-IP addresses is also more cumbersome

	I still believe this is enough...  you just need to filter out
	things you don't want to look at.

	/* lookup by PF_UNSPEC */
	for (res = res0; res; res = res->ai_next) {
		if (res->ai_family != AF_INET && res->ai_family != AF_INET6)
			continue;
		s = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
		connect(s, res->ai_addr, res->ai_addrlen);
		close(s);
	}

itojun

---

From: [email-masked]
Date: Mon, 17 Jan 2000 23:46:24 +0900

>	things you don't want to look at.

	I wasn't clear enough.  I actually read the last line.
	at this moment, on most of the platforms PF_UNSPEC returns AF_INET6
	and AF_INET only :-) so this is not a big issue even if we filter them
	out manually.

	what I fear is, by introducing "v4 and v6 only" option to getaddrinfo,
	we may decrease getaddrinfo's address family independency.
	by using getaddrinfo careful enough, your application can become
	very future proven,  by hardcoding "v4 and v6 only" option argument
	to getaddrinfo, now you are not future-proven (you apps will not work
	for other AFs).

itojun

---

From: [email-masked]
Date: Mon, 17 Jan 2000 23:46:24 +0900

This mail is automatically sent to you from the NRJ E-mail system.
The contents of this mail refers to the mail sent to you from
[email-masked] with the subject "Re: API suggestion ".
 
Information regarding NRJ e-mail addresses.
 
Since installation of the new e-mail system, last summer. The old e-mail
address and the new have been configured to route received mails to same
mailbox. This is a temporary solution to make it possible for all NRJ
employees to inform business contacts about the new @nrj.ericsson.se
e-mail address.
 
Please be aware of that receiving service of old NRJ e-mail addresses
ending @ericsson.co.jp will be stopped from February 15th.
 
Only the addresses ending @nrj.ericsson.se will be valid and accepted in
our e-mail system from February 16th and old address will bounce
back to the sender.
 
From January 17th to February 15th you will get this e-mail notification
if an e-mail is sent to you, using the old address.
In that case, you have to inform the sender of your new address.
 
Your business card shall have the new address [email-masked]
printed.

Best Regards
 
IS/IT HelpDesk

---

From: [email-masked]
Date: Mon, 17 Jan 2000 23:41:56 +0900

Best Regards
 
IS/IT HelpDesk