From: Boris (boris_at_[hidden])
Date: 2005-03-13 18:15:49
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
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
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
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
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. ;)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk