[boost] Re: [network] An RFC - updated

From: Michel André (michel.andre_at_[hidden])
Date: 2005-04-22 02:01:48

Don G wrote:
> The crux of what I am proposing is a layer that encapsulates sockets
> behind an abstraction, which would place it between sockets and
> ACE-like designs or whatever else.

Or even higher up abstraction, since it could be built on top of more 
lower layer ACE/socket apis ;).

> Many, but not all, implementations of that abstraction would be based
> on sockets, select, epoll, kqueue, etc.. At my work, where this
> design was born, we have a direct serial implementation and an
> HTTP-tunnel implementation. We have also implemented the stream
> abstraction for NT named pipes and SSL (using OpenSSL). By virtue of
> the abstract nature of things, we can use SSL over named pipe for
> example. Or SSL over serial line (you get the idea<g>).

The abstraction also imposes a lot of choices on threading and memory 
managment. Like creating threads behind you back and such that could be 
a problem. Eg calling a com object on a callback thread in Windows needs 
CoInitialize to be called and so forth. So just creating threads behind 
the back and do callbacks to user code is a problem. Of course you could 
and should provide a thread init hook or something to that matter.

> I have acceptor in my proposal, but connector didn't seem (to me) to
> be an entire class/object. I have an address object as the Abstract
> Factory for a stream object, which is similar to a connector concept
> except that the connection process begins with a method on the stream
> object. In other words, the stream is created in an unconnected state
> and it is that stream that we want to connect. This felt like a much
> better fit to the problem at hand (again, to me<g>).

I see no problem with this. The only thing an connector gives you is the 
possibility to do some hand shaking or whatever before handing the 
stream to the handler and this handshacking wouldn't be relevant to the 
protocol handler.

> The layer is conceptually complete (or should be made so by adding
> new abstractions). The only reasons I see for going around the layer
> I propose would be: use of platform-specific features or performance.

How would you write a single threaded reactive server or client?

/Michel