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:
> As usual any comments are appreciated,
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk