[boost] Re: Sockets: proposal for a library design

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 
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket/SocketRequirements. 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

> [...]