Re: Developing IP version-independent Applications

[Pekka Savola <pekkas@netcore.fi>]

inline..

(I waited for other comments, but they didn't appear :)

On Mon, 17 May 2004 js.jason.lin@foxconn.com wrote:
> On Sat, 15 May 2004 js.jason.lin@foxconn.com wrote:
> This allows eliminating the compile-time special casing from the code,
> making the code simpler.
> 
>       <jason>
>       I am not sure whether most IPv4-only really support such getaddrinfo
> or getnameinfo
>       API. But I am afraid to add a version of getaddrinfo/getnameinfo into
> applications can be much
>       complicated than using conditional compilation.
>       <>

Depends a lot on how the code is designed.  If you create your own
network connectivity manipulation functions, it should be quite easy
to make them conditional.  If you don't, you'll have to sprinkle
conditional conditions all over your code.  And that's a pain to 
maintain as well.

There's no winner or loser here.  I'm familiar with some open-source 
projects; most use only getaddrinfo and provide background 
compatibility code as appropriate.  Some others provide conditionally 
either at compile time.

It's a judgement call for the developer, and I'm not sure whether this 
needs text in this document.  It might be good to spell it out.  Do 
you have text suggestions?
 
> Further, the IPv4-only operation is most important in practice for
> nodes which already would be able to support IPv6, but the support is
> turned off.  The applications should continue to work under those
> circumstances.
> 
>       <jason>
>       I think this is really a good reason for "version-independent"
> programming.
>       In embedded system, whether to activate IPv6 or not is usually
> determined in compilation time.
>       However, for PC, IPv6 really can be changed dynamically.
>       <>

Totally agree here, and this was the most important original reason 
for adding this ipv4-only section.
 
> Maybe the justification for this should be clarified a bit?  Would you
> have ideas how to do that?
> 
>       <jason>
>       IMHO, the key value of "version-independent" API is for the
> situations where IPv6 can
>       be DYNAMICALLY disabled. And before we claim the application written
> in "version-independent" API
>       can run in IPv4-only platform, we'd better make sure these
> "version-independent" API is supported in
>       those legacy IPv4-only platform in advance.

Yes, that's probably the most important case.

>       Finally, I have one more related question:
>       If my platform supported IPv4-mapped IPv6 address and the IPv6 won't
> be disabled forever.
>       Then for TCP server application, do you think it is enough to create
> one IPv6 socket to
>       server IPv4 and IPv6 TCP client? Or we still need to create two
> sockets, one for each version,
>       like the sample code described in Sec 6.3.1?
>       <>

The document takes no firm stance here, on purpose.  You have to make 
that decision based on the tradeoffs such as portability (some systems 
don't support mapped addresses), how you tread the addresses (e.g., 
whether you want to parse mapped addresses or v4 addresses), etc.

As for my personal opinion, I'd go for two sockets for long-term
projects, and possibly for one socket in some limited short-term
hacks.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings