Don G wrote:
[...] I would suggest that a proposed Boost.Net library should focus on networking in a more abstract manner, and not be merely a socket encapsulation. IMHO, sockets are a terrible API and should be hidden as fast as possible. A socket wrapper class is appropriate, but I would not go to any trouble to change the socket API. Simply wrap the resources and provide portable access to the underlying system. The real end-user part of the Net library should not talk about sockets (unless one provides a method like get_native to return the socket handle, and that method is defined as non-portable).
This reminds me of the layers requirement from http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/S.... I agree that it would be nice to have some easy-to-use high-level classes for concepts that are used in network applications again and again.
I think all desired I/O models should be available at run-time (see below). In my own work in this area I have seen that this approach does not greatly effect the implementation. In other words, there is virtually nothing to be gained by making async I/O optional at compile-time.
I agree again. There shouldn't be any of the four I/O models omitted. We will see as we proceed if supporting various I/O models is easy to implement and to use at runtime (especially switching between I/O models).
As others have also suggested, I would agree that the net facilities not be tied up into I/O streams. It would be better to provide the network facilities and then layer on I/O streams for those that want it.
Several people dislike the idea of a network library built on I/O streams. What are the reasons for this? Is this a request for a more low-level access to socket functions like read(), write(), send() and recv()? The only reason I see why I/O streams should not be used is the lack of support for an asynchronous I/O model. The network library would have to add functions for asynchronous support until one day I/O streams support an asynchronous I/O model by default (btw, anyone working on this?).
There are really only a few abstract entities to worry about: Url, Address, Stream, Datagram, Acceptor. In my work (not related to Boost), I've also created a Network class to serve as the abstract factory and contain a thread pool for doing the async I/O. I believe your diagrams use "Client" and "Server". I think these terms are a bit too generic. I prefer the term "Acceptor".
Thanks, I renamed client and server to connector and acceptor.
Usage examples:
Thanks again! When the socket class hierarchy is more stable I hope to move upwards to high-level classes representing concepts from the network world you used in your examples.
[...] One thing I think is essential when using a blocking model is cancellation. For example, I have a reset() method on Acceptor, Address, Datagram and Stream that can be called at any time to cause blocking methods to terminate with a cancel exception (obviously this must be from another thread). Ironically, these reset() methods meant I could not use blocking socket calls to implement my blocking methods - recv() cannot be canceled once it blocks (at least not portably)!
I added this to the Wiki but I am not sure if a network library should support it. If you have two threads in your application and one thread is halted because of a blocking call it might have been better to use a nonblocking/asynchronous I/O model?
[...] Whew! Slightly more than $0.02, I know. :)
Thank you very much - that's much better than reading nothing at all. ;) Boris
[...]