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

From: Boris (boris_at_[hidden])
Date: 2005-04-22 14:34:19

Don G wrote:

Hi Don,

> [...]
> So, yes, I do think we need this layer or one much like it. And it
> must be much lower level than <iostream>. The abstraction I proposed

I think socket streams are no competitor anyway. An ACE-like library and 
socket streams can be both built on top of level 0 so they both live in 
level 1. While socket streams offer blocking and maybe non-blocking I/O 
using the familiar stream interface the other packages in level 1 should 
have clear goals, too. The package in 
http://www.highscore.de/boost/net/packages.png I called "ace" was introduced 
after my discussion with Michel. We talked about acceptor-connector pattern 
and service handlers, and I think these concepts can help developers using 
the network without any idea of sockets and how they work.

That said I am trying to find out what your library offers to understand if 
it belongs to the same package which is called "ace" right now. Or your 
library has different goals which means we need another package in level 1 
or even worse a new level. In the end the network library can and should 
consist of different packages to meet different requirements but it should 
be very clear to library users which requirements are met by each package.

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

As far as I understand the acceptor-connector pattern the idea is that a 
connector behaves like an acceptor. This means both of them are factories 
producing connected streams. Most network developers (who know Berkeley 
sockets) will probably create an acceptor based on accept() and a connector 
based on connect(). The acceptor will work as a factory but the connector 
can probably be used only once to create one connected stream. This is what 
I did in http://www.highscore.de/boost/net/basic.png and comes close to the 
C API. If we think of unexperienced developers who don't know any sockets 
they will probably be happy if the connector behaves like the acceptor as 
they wouldn't understand the difference. Regarding the acceptor and 
connector your library seems to be close what I made up in the class 
hierarchy and therefore would belong to level 0.

> [...]
> My goal is to iron out a behavior contract that satisfies various
> possible and desired implementations, so that a library user can know
> what are safe and portable practices. One could say that the sockets
> API does this, but there are two central issues: one cannot create a
> new type of socket (to layer protocols); not all forms of I/O
> completion are portable.

I am surprised to read this! The socket API - the so-called level 0 - must 
and will be portable. It should be possible to derive classes from socket 
and create new types. And all four types of I/O must be supported in level 
0, too. What kind of problems do you see here?

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

If the network library should support platform-specific features we should 
indeed add another package to 
http://www.highscore.de/boost/net/packages.png. This package would be 
optional. However it would be nice if classes from this package would 
collaborate somehow with classes from the other non-optional packages of the 
network library. The non-optional packages would provide a default 
implementation and library users could use optimized classes from the 
optional package depending on the platform they are using.

> [...]
> I hope I have answered your questions.

Yes, thank you very much! Sorry to have some new questions now. :)

Boris