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