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

From: Michel André (michel.andre_at_[hidden])
Date: 2005-04-12 12:31:47

Boris wrote:
> 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.

Yes, I tried do have a more abstract notion than socket which is quite 
concrete to me and one way of implementing an io_stream.

>>[...] 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?

It should be exposed and could be used to hook other things to the event 
dispatcher (of course this would maybe need a custom event_dispatcher or 
some knowledge of the implementation of the event_dispatcher).

> 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. :-)

Yes i wanted to separate connection establishment and the stream 
handling completely since it's typically often the case for a server 
that you initiate listening on some well defined end points on different 
protocols and then like the actual connections and byte stream protocols 
to be alike irrespective of how the connection/stream was constructed. 
The socket class hierarchy doesn't make sense to me given we an acceptor 
inheriting from socket which would have send and receive ops but send 
and recv arent allowed on a listening socket only accept.

>>[...] 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 don't think its possible or feasible to decouple the event handling 
completely since at least all notifications mechanisms for io handles 
fds that I know of is tigthly couple to platform specific primitives 
like iocp/kqueues/select and its not that easy to mix and match events 
at least not on all mechanisms and plattforms.

> 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.

Thanks I looked at it and it gives a good overview. I think this one 
gives a good summary as well http://www.kegel.com/c10k.html. I'm notto 
fond of the hierarchy of sockets as I mention above eg you cant read 
write from an listening socket, although i think the taxonomy of the 
hierarchy is great.

/Michel