From: Boris (boris_at_[hidden])
Date: 2005-03-04 19:18:47
Caleb Epstein wrote:
> On Thu, 3 Mar 2005 01:13:58 +0200, Boris <boris_at_[hidden]> wrote:
Caleb, thanks for your comments! There is not much feedback so appreciate
any comment. I wonder if there's a lack of interest or some resignation as
the socket stuff is in the Wiki for ages without any progress.
> * 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.
You are right, I agree.
> * 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.
I agree again. The operators in class socket are an example to show where
read- and write-methods will be implemented (whatever they will look like).
> * Server should probably be a factory of sockets. I don't think
> client and server should be concepts at the root of the hierarchy.
I'll have a look at the net library in Java and .NET. I hope to create UML
diagrams for these libraries, too. Then we should get an insight into
differences and possible advantages of their designs. I'll post to this
newsgroup whenever I update the Wiki.
> * 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.
That's what the class multiplexing represents (in namespace
By the way, what do you think about the .NET way? In .NET there are only two
models: synchronous and asynchronous. Synchronous is the same as blocking
but asynchronous depends on the implementation (from multiplexing to
signal-driven to real asynchronous is everything possible). Does it matter
to a library user how asynchronous is actually implemented?
> * Picking nits, they are "Berkeley" sockets, not "Berkely".
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk