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