[boost] Re: async socket i/o [long]

From: Boris (boris_at_[hidden])
Date: 2005-04-11 17:37:55

Michel André wrote:
> There has been some discussion on this on the list lately. Is there
> anyone working on it. I have been pondering an interface that supports

Yes, but I had no time lately. See 
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet for 
what we have now. However I still have to update the page after the 
socket/async IO/pure async discussions to add latest thoughts.

> both async and blocking io combined. And an event dispatching model
> that can handle several types of dispatching mechanism through a the same
> interface to provide for a lot of differnet implementations.
>
> At heart of this is an io_stream base class that should serve as base
> for classes like tcp_stream and udp_stream.

The interface of io_stream looks good. This class is called socket in the 
UML diagram you find at the bottom of 
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet.

> [...] the event_handler interface is at heart of event handling and
> dispatching.

Is the event_handler exposed to the library user or an idea how to implement 
the event stuff internally? At first I thought it's an implementation detail 
but after thinking a while it looks like an object-oriented select() 
replacement?

> [...] To top this of we have connector and acceptor base classes

Your connector and acceptor are inherited from event_handler compared to the 
class hierarchy at the bottom of 
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet 
where they are inherited from socket. Your design is similar to the one in 
.NET where TcpClient and TcpListener use Socket but are not inherited from 
Socket. I have no opinion right now which one to favor - I guess it comes 
down to definitions and concepts. I'll think about it. :-)

> [...] What are your initial thaugths on this, implementatble? flexible
> enough? efficient enough?

Your design comes close to what we have in the Wiki. After the long 
discussions about async I/O and a pure asynchronicity library I would like 
to see an asynchronous design pattern for Boost first that not every library 
reinvents interfaces for asynchronous operations. Besides that someone 
proposed to concentrate on an async I/O library first and base the 
asynchronous operations of a network library on this. You started to create 
an interface for async I/O already so maybe you can decouple it (or is this 
the event_dispatcher/event_handler part?).

I'll try to update the Wiki page about the network library as soon as 
possible to give a summary about what has been discussed in the async 
threads. If you have time please read 
http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet - I 
look forward to your feedback.

Boris