From: Pedro Lamarão (pedro.lamarao_at_[hidden])
Date: 2006-01-05 17:13:56
Christopher Kohlhoff wrote:
> - Is it worth keeping separate ipv4 and ipv6 namespaces?
> Some applications may want to explicitly specify one or the
You can consider it from the operating system upwards.
In modern Windows and Unixes best practice is to use getaddrinfo and
getnameinfo for translation to and from network and human address
representation, and these calls work portably with IPv4 and IPv6
Every function call for whom the network family is relevant receives
this information at runtime, and not at compile time. (Like, say,
wprintf is hardwired to the wchar_t character type.)
So separating IPv4 and IPv6 into almost two separate libraries is not
something the operating system forces or suggests. What kind of
usability does it provide?
> - How does this fit with Giovanni Deretta's suggestion of
> separate types for each protocol's socket? Does it mean having
> an asio::ip::tcp::socket type, for example? The issue is that
> the concrete protocol (IPv4 or IPv6) needs to be known before
> the socket object is opened.
Something like this?
template <int FamilyT, int StyleT, int ProtocolT>
It provides static knowledge of "family" and "style" that could be
useful if you want to do some magic with the endless amount of flags and
parameters for getsockopt and setsockopt specific to each, and gives us
a neat default constructor. Otherwise, where would this information make
a difference at compile time? Maybe validating generic address objects
passed to connect or bind or whatever, or making getsockname and
getpeername easier to use?
Me, being a big fan of IOStreams, dismissed quickly this approach while
trying to work with:
// Lots of static structs to wrap all those ints
template <typename CharT,
It's just too ugly.
-- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business