Re: [boost] asio review -- IPV4/V6 issue

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-01-12 08:19:46

Hi Pedro,

--- Pedro Lamarão <pedro.lamarao_at_[hidden]> wrote:
<snip>
> 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?

I was thinking more in terms of the ability to directly
manipulate addresses, endpoints etc for only one type. I.e. in
applications where you do not want automatic runtime support for
both IPv4 and IPv6. These applications shouldn't need to check
the type of an address at runtime if compile-time checking is
available.

However I am asking the question of whether it is valuable to
retain the separate types because I don't know whether such use
cases do exist, or are common enough to warrant maintaining this
support.

> Something like this?
> 
> template <int FamilyT, int StyleT, int ProtocolT>
> class socket;

Actually the template parameter would be an implementation
of the Protocol concept:

  class Protocol
  {
  public:
    int family() const;
    int type() const;
    int protocol() const;
    ...
  };

This still allows the protocol to be determined at runtime, if
necessary (as it is to dynamically support both IPv4 and IPv6).

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

Yep, these last reasons are the motivation for these changes.
I.e. adding compile-time type safety in dealing with socket
types.

> 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,
>           typename TraitsT,
>           typename FamilyT,
>           typename StyleT,
>           typename ProtocolT>
> class basic_socketstream;
> 
> It's just too ugly.

Yes :) However from the user's point of view, the changes I'm
planning would look more like:

  ip::tcp::endpoint ep(1234, "::1");
  ip::tcp::socket s(io_service);
  s.connect(ep);

Cheers,
Chris