[boost] asio networking proposal

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-08-18 09:22:16

As discussed in the "surveying async network io libraries" thread, I'd
like to turn asio (asio.sourceforge.net) into a proposal for a boost
networking library. As promised, here is a list of areas where asio
could use some refinement.

I'd appreciate input on:

- What people think of the relative importance of the items. For
  example, what would be required for an initial implementation vs
  what could or should be left until a later revision.

- Whether the proposed changes are of any value.

- Any other things that should be on the list.

What's Missing
==============

* Asynchronous DNS operations. I think it would be reasonable to say
  that any operation that can block should have an asynchronous
  equivalent. Should these operations be cancellable (not necessarily
  portably implementable anyway)?

* IPv6 support. I have no experience with IPv6, so it would be great
  if someone with experience could help out with the design here.

* Asynchronous socket close. In certain circumstances closing a socket
  can block, so it would be reasonable to expect an asynchronous close
  operation.

* Scatter-gather operations (sendv and recvv).

* The BSD socket functions sendmsg/recvmsg (which I believe are
  necessary to support protocols such as SCTP).

* SSL/TLS and DTLS support. This would require an external library,
  and how does that fit in with boost?

* Other protocols (PF_UNIX, ...)?

* Some type of integration (or support for) a higher-level
iostreams-based socket library.

* More examples.

* Documentation on design and rationale.

What Should Be Included and What Shouldn't
==========================================

* Obviously asio::thread should not be part of a boost proposal,
  since that functionality is already covered by Boost.Thread.
  
* The asio::time class should probably not be included, and
  wherever it's used replaced by Boost.Date-Time.

Naming and Structure
====================

* The use of the word "Stream" can be confusing because its existing
  association in C++ with iostreams. Can anyone suggest an
  alternative?

* Should stream_socket and dgram_socket be merged into a single socket
  class? There other types of sockets (e.g. sequenced packet) that
  would require additional classes if the current approach is
  retained. This would not be required if the BSD socket APIs were
  covered by a single class. Alternatively, should additional classes
  be added for the other socket types?

* The current separate socket_connector implementation does not
  correspond to an OS resource, unlike socket_acceptor. This can
  be problematic, e.g. it prevents a Windows implementation using
  ConnectEx, and doesn't allow you to set socket options before the
  connection is established. Therefore I propose adding connect and
  async_connect operations to socket classes. Should the separate
  socket_connector be retained?

* In designing asio I considered that people may want to customise
  the demultiplexing strategy associated with each resource. For
  example the basic_stream_socket template looks like:

    template <typename Service>
    class basic_stream_socket;

  where Service is a "facet" of the demuxer that provides
  demultiplexing facilities for the socket. The typedef for
  stream_socket specifies the Service type based on the target
  platform.
  
  However in practice I don't believe this level of customisation is
  required (to the best of my knowledge no existing asio user
  customises it), particularly if asio uses the "best" demultiplexing
  mechanism for each platform. Or another way of looking at it:
  developers who need this level of control might not use a general
  purpose networking library anyway.
  
  An alternative approach would to have the only template parameter be
  an allocator (since there is often memory allocation associated with
  asynchronous operations). For example:

    template <typename Allocator>
    class basic_demuxer;

    template <typename Allocator>
    class basic_stream_socket;

  where a stream_socket can only be used with a demuxer that has the
  same allocator type. The typedefs for demuxer and stream_socket
  would just use the default allocator.

Cheers,
Chris