Re: [boost] asio networking proposal

From: Ariel Badichi (abadichi_at_[hidden])
Date: 2005-08-19 17:20:16

Christopher Kohlhoff wrote:

[snipped parts irrelevant to my reply]

> As discussed in the "surveying async network io libraries" thread, I'd
> like to turn asio (asio.sourceforge.net) into a proposal for a boost
> networking library. As promised, here is a list of areas where asio
> could use some refinement.

Great!

> 
> - Any other things that should be on the list.
> 

I experimented with the library for a few days now. Maybe I'm misusing
it, but it seemed nice to have demuxer::run() thread(s) running before
any (meaningful) asio operation is performed.

My solution was a demuxer::run() thread pool management class (using
boost::thread_group to manage the threads themselves). The class has a
timer that keeps queueing itself in its handler, unless the class's
client requested it to stop. The stop operation also joins the thread(s).

If it's a legitimate use, a helper class to do that can be useful. If
not, why?

> 
> * More examples.
> 
> * Documentation on design and rationale.
> 

These are the two most important improvements.

> 
> * The use of the word "Stream" can be confusing because its existing
>   association in C++ with iostreams. Can anyone suggest an
>   alternative?
> 

The use of "stream" in this context seems natural enough for me. I
suspect most people writing networking code will agree.

> * Should stream_socket and dgram_socket be merged into a single socket
>   class? There other types of sockets (e.g. sequenced packet) that
>   would require additional classes if the current approach is
>   retained. This would not be required if the BSD socket APIs were
>   covered by a single class. Alternatively, should additional classes
>   be added for the other socket types?
> 

My instinct tells me that they shouldn't be merged: they are very
different concepts, and I wouldn't like this specific abstraction
eliminated in asio.