From: Scott Woods (scottw_at_[hidden])
Date: 2005-03-14 00:19:20
----- Original Message -----
From: "Boris" <boris_at_[hidden]>
Sent: Monday, March 14, 2005 12:38 PM
Subject: [boost] Re: Re: Sockets: proposal for a library design
> I don't know who wrote the socket requirements. I just felt that I
> ignore them. If there are any other requirements I would be happy to hear
> them. Eg. it seems like we found a new requirement these days as several
> people dislike the idea of a I/O streams based network library. I/O
> support seems to be desired only on a higher level?
> > [...]
> > Perhaps a reason that noone has designed a really great sockets
> > library
> > yet is that there is little practical reason to, as BSD sockets is
> > probably more portable (from a practical standpoint) than a Boost
> > library will ever be, and libraries try to that "abstract" it have
> > done nothing but get in the way.
> Most developers probably make a decision which I/O model they want to
> support and forget about the rest. As there are four I/O models it doesn't
> make much sense if they are implemented by different developers again and
> again. This should be a very good reason to create a C++ network library.
I too find the models confusing and believe that confusion to be avoidable.
Adoption of I/O streams is also an intellectual struggle and (again) a
struggle that may be avoidable.
Networking is inherently asynchronous. Initiation and acceptance of
connections and I/O may be disguised as synchronous but other activity (e.g.
"network down") cannot. Network APIs will often defer such errors until
the next reporting opportunity (e.g. next I/O request) but this is a
that is sometimes enough and at other times downright misleading. I assume
that something going by the name of Boost.Net would be targeting a higher
Proposing that all network communication is asynchronous does not
preclude any synchronous coding. As discussed in other threads (i.e. RPC) a
"low-level", asynchronous library may be the "core" of a Boost.net while
services may be built on top.
I have implemented this combination of "co-operating models" more than
once and it has turned out OK (or better :-)
One of the more recent challenges has been the integration of
of network libraries into different application frameworks - much pain
the lack of a standard framework is holding back development of several
Without some means to create co-operating components (e.g.sockets manager,
file I/O and timers) the different parts become islands. This situation is
soonest encountered around 3rd party frameworks and networking.
I think an asynchronous, core Boost.Net should expose fundamental network
services. In the case of TCP, that would be the reliable, async 2-way
data blocks. Achieving a clean and portable library at this level would be
enough. Dragging I/O streams into the "network discussion" at this point is
premature; it moves the focus up the network stack. Again this doesnt
those who need to from integrating with I/O streams at a later point.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk