Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk