Re: [boost] Re: Re: Sockets: proposal for a library design

From: Scott Woods (scottw_at_[hidden])
Date: 2005-03-14 00:19:20

----- Original Message -----
From: "Boris" <boris_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, March 14, 2005 12:38 PM
Subject: [boost] Re: Re: Sockets: proposal for a library design

[snip]

> I don't know who wrote the socket requirements. I just felt that I
shouldn't
> 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
streams
> 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.
>
> Boris

Hi,

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
band-aid
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
sophistication.

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
synchronous
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
implementations
of network libraries into different application frameworks - much pain
involved. IMO
the lack of a standard framework is holding back development of several
Boost libs.
Without some means to create co-operating components (e.g.sockets manager,
GUI,
file I/O and timers) the different parts become islands. This situation is
perhaps
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
transfer of
data blocks. Achieving a clean and portable library at this level would be
achievement
enough. Dragging I/O streams into the "network discussion" at this point is
almost
premature; it moves the focus up the network stack. Again this doesnt
preclude
those who need to from integrating with I/O streams at a later point.

$0.01

Cheers,
Scott