[boost] Sockets

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-11-24 10:58:51

In my experience in attempting to develop an over-general sockets
abstraction, it is next to impossible to contrive a perfect generalization
of the many different socket types.

A good sockets implementation will at a minimum:

* Use polymorphism on a well-defined socket interface.
This will allow code to be written that is protocol neutral and easy to
maintain. This is also a better choice over attempting to create an overly
complex do-all 'socket' class that takes an enum to try and determine the
protocol desired--I think everyone will agree that attempting to use GP and
Policies will be just as messy here. The implementation will be much cleaner
when small, specialized implementations are allowed.

This approach will also trivially allow extensibility (even by the
boost::end.user) to support other implementations that can be submitted
without affecting existing implementations.

Also, specific protocols should get their own sub-namespace.

* Separate Reading/Writing versus Connecting or Accepting connections.
There are a few ways to do this, either by having a pure interface that
defines reading or writing and an object (kind of factory?) that will accept
connections or create new ones. This seems like a good approach because it
distills functionality between the two main needs of sockets. It also may
ease development because in general, on a given platform, I/O on a socket is
usually identical and not dependent on the protocol, where connecting is.

However, this may go against the desired user convention, which needs to be
decided over and before any implementation convenience. It may be decided
that sockets have a constructor that take an (protocol-specific) address
class (implicitly constructible by a char const*) for opening connections,
and there is only a listening service type class that takes in new
connections and returns a socket that is already connected.

* Support for Event-Driven and Blocking sockets
This one should go without saying. The event-driven support can trivially be
provided in the pure socket interface and easily created using tools like
boost::signals or boost::function.

** Thread Pool
For event-driven sockets, a thread per socket can sometimes be wasteful, so
there may be support for using a thread pool that monitors for events on the
sockets in an application.