Re: [boost] Sockets

From: Caleb Epstein (caleb.epstein_at_[hidden])
Date: 2005-03-04 16:42:38

On Thu, 3 Mar 2005 01:13:58 +0200, Boris <boris_at_[hidden]> wrote:
> There hasn't been much talk about a socket library recently. The Wiki stuff
> about sockets is quite old so I don't know if Hugo is still working on it?
> It's some time ago I added some proposals for a multiplexing library to the
> Wiki. So I went through most of the Wiki pages of Boost.Socket and
> Multiplexing and tried to gather and sort the ideas a bit. As I don't want
> to go even more into details by adding more C++ code I tried a
> top-down-approach using UML diagrams. Without sorting the ideas and getting
> a big picture we are stuck in the details and don't proceed. The network API
> isn't small, there are many different goals to reach and the network library
> might overlap with other libraries - quite a lot to do. :-)
> 
> So here is the next small step:
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet
> 
> As usual any comments are appreciated,
> Boris

Some good stuff up there.  I have a couple of comments:

* blocking/nonblocking mode must be selectable at run-time.  Having a
default selectable at compile time is fine, but not allowing a switch
at runtime would be too limiting.

* Don't model sockets on iostreams.  They don't model non-blocking I/O
correctly (see Jonathan Turkanis's recent posting on the evolution of
the Boost.Iostreams interfaces).  Simple methods called read and write
should be sufficient.

* Server should probably be a factory of sockets.  I don't think
client and server should be concepts at the root of the hierarchy.

* To implement a scalable server-side application there must be
support for IO multiplexing (e.g. select/poll/etc) and this should be
considered in the design.

* Picking nits, they are "Berkeley" sockets, not "Berkely".

-- 
Caleb Epstein
caleb dot epstein at gmail dot com