Caleb Epstein wrote:
On Thu, 3 Mar 2005 01:13:58 +0200, Boris <boris@gtemail.net> 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 boost::net::iomodel)? 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".
Thanks, corrected! Boris