From: Boris (boris_at_[hidden])
Date: 2005-04-22 14:34:19
Don G wrote:
> 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. :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk