On Thu, 3 Mar 2005 01:13:58 +0200, Boris <boris@gtemail.net> 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