Boost logo

Boost :

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-31 02:01:38

Hi Jeff,

--- Jeff Garland <jeff_at_[hidden]> wrote:

> A group of folks here in Phoenix got together and had a little
> asio 'review party'.

Times must be tough to need asio as an excuse for beer ;)

> As was discussed early on in the review asio doesn't currently
> support ipv6. However, going forward ipv6 support is critical
> for the "Phoenix Group". Given the current asio interfaces it
> seems clear that the extension will come in the form of
> another namespace -- presumably asio::ipv6. This means that
> client code will need to be modified to make the upgrade to
> ipv6. The need to modify code for ipv6 support was disliked by
> the group. It was the consensus of this group that it would
> be preferable to explore a solution that could support both
> ipv4 and ipv6 addresses seemlessly without changes to client
> code. Part of the rationale for this is that most applications
> don't directly configure the ip addresses in code, but rather
> read them from configurations. Hence it would be nice if the
> upgrade was as simple as swithching over the configuration.
> Thus the same compiled app could directly support ipv4 and
> ipv6.
> Thoughts, discussion?

I must preface this by saying I have virtually no IPv6
experience, so feel free to jump in and contribute or correct

In the current design I think this could be accomplished by
adding a new asio::ip namespace that contains:

- An address class that can contain either IPv4 or IPv6 host
  addresses, with functions for converting to and from strings
  (much as asio::ipv4::address does already). It includes a
  function that tells the type of the contained address.

- A host class that contains host names and associated list of
  IPv4 and IPv6 addresses.

- A host_resolver class that resolves host names into a list of
  both IPv4 and IPv6 addresses (if a host supports both).

- A tcp class which is an implementation of the Protocol concept
  (as asio::ipv4::tcp is). However unlike asio::ipv4::tcp this
  one does not return constant values and does not have a
  default constructor. Instead it takes an enum indicating
  whether the protocol is for IPv4 or IPv6, and the values
  returned by its member functions vary accordingly.

- A tcp::endpoint class that contains an address object and a
  port number. The protocol_type typedef for this object is for
  the asio::ip::tcp class.

- The tcp::endpoint::protocol() member function returns a tcp
  object constructed for either IPv4 or IPv6 depending on the
  type of the address object that it contains.

- A similar implementation of this for the udp class.

Some examples:

// Binding to an IPv4 localhost address using a string:
asio::ip::address address("");
asio::ip::endpoint endpoint(12345, address);
asio::datagram_socket socket(demuxer);;

// Same as above using IPv6.
asio::ip::address address("::1");
asio::ip::endpoint endpoint(12345, address);
asio::datagram_socket socket(demuxer);;

// Host resolution and connection.
asio::ip::host host;
asio::ip::host_resolver host_resolver(demuxer);
host_resolver.get_host_by_name(host, "foobar");
asio::ip::endpoint endpoint(12345, host.addresses(0));
asio::stream_socket socket(demuxer);

Assuming this works...

- Is it worth keeping separate ipv4 and ipv6 namespaces?
  Some applications may want to explicitly specify one or the

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at