Re: [boost] Re: Re: Re: Re: Re: (Another) socket streams library

From: Scott Woods (scottw_at_[hidden])
Date: 2005-04-27 17:47:37

Hi Boris,

----- Original Message -----
From: "Boris" <boris_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, April 27, 2005 9:47 PM
Subject: [boost] Re: Re: Re: Re: Re: (Another) socket streams library

> Scott Woods wrote:
> > [...]
> > Yeah, tricky stuff. After several attempts with varying levels of
> > success
> > the
> > following is the most complete and efficient that I have come up
> > with. This is specifically to deal with "streaming" over async
> > sockets. This may ramble a bit
> > but hopefully with purpose :-)
>
> If I understand correctly your socket streams support blocking I/O.
However
> I/O methods are guaranteed to return immediately as data is copied to the
> so-called "application zone" where it waits until it is sent to the
network?
>

Yes to the first question (i.e. blocking I/O).

Not clear on what you were asking in the second. I'll try the shotgun
approach
and hope I hit something :-)

Streaming operations might be characterized as "application-object-centric"
(and
rightly so!). Operations in the "application zone" involve the sending of
application
objects to a "stream".

Async I/O operations might be characterized as "network-event-centric". Code
responding to network notifications (e.g. ready-to-send) is focused on
making
as much of the opportunity as possible (e.g. present the maximum amount of
data
to the network API).

The data flow sketched out in my previous mail, has two "buffers". The first
lives between the application and network zones. The second between the
"network
zone" and the actual network API (e.g. ::send).

Full justification for the "double buffering" is probably out of scope here;
it does
relate to the general need for async behaviour "intra-process".

The point of presenting it at all was more about the un-coupling of
streaming
output operation from the actual I/O operation. Relating the streaming of an
application object to a subsequent I/O error is very difficult. I
specifically
include the detection of such errors on "flush". After taking another
approach
not only has my mood improved but I now even consider the possibility that
relating application streaming operation to the ultimate ::send/::write
is.... wrong?

My approach to input is (inevitably? ;-) completely different. There are no
"operator>>( stream &, application_object & )"'s to match the output
operators; the design is asymmetric. This is for the simple reason that a
function with such a signature implies blocking; it must wait for
potentially
multiple network reads to complete the application_object. The design
is fully async.

Did I hit anything?

Cheers.