Re: [boost] Re: Re: Re: Re: Re: Re: Re: Re: (Another) socketstreamslibrary

From: Scott Woods (scottw_at_[hidden])
Date: 2005-05-05 18:48:38

Hi Boris,

As you said somewhere; there has been "heavy discussion". Almost sounds
like something that parents might disapprove of.

----- Original Message -----
From: "Boris" <boris_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, May 06, 2005 9:50 AM
Subject: [boost] Re: Re: Re: Re: Re: Re: Re: Re: (Another)
socketstreamslibrary

> Scott Woods wrote:
> > [...]
> > I feel as if we have clarified one thing; there can be no iostream
> > input operators
> > over async sockets (the function signature is blocking). Which leaves
> > the output
> > operators and whether iostream output operators over async has any
> > value?
>
> The async implementation you proposed can be supported by blocking I/O

Was that the wee table of libs in an previous message?

> functions as far as I understand (or should I say blocking O functions :-)
> as the whole asynchronicity is hidden behind the interface. The only
> difference to the standard blocking I/O functions is that your
> implementation guarantees that blocking I/O function return immediately
> (which is of course no problem and might be useful for library users).

Nathan and I have been through a recent exchange of mail. Its been
interesting
and for me at least there has been a conclusion.

Iostreaming over sockets running in asynchronous mode are possible. Its
just not a goal for me. Thats not because I dont need asynchronous software,
in fact, quite the opposite. An asynchronous application is more difficult
to
write using streams over async sockets. At best.

Taking a simplistic telephony example;

A PBX is establishing a call between two phones. Imagine these phones are
in communication with the PBX software over separate TCP connections
(i.e. sockets in async mode).

Using the iostream model there will be calls such as;

    calling_phone >> telephony_message;

If "calling_phone" is the istream for one of the TCP connections then the
caller (of operator>>) is committing itself to the completion of the next
message from that phone.

What happens if a message arrives from the other phone, on the other
stream, before a message is completed from "calling_phone"?

IIUC, Nathans approach (and an approach consistent with traditional
iostream software) would involve two threads - one for each phone
stream. Received messages would be transferred to the PBX component
as a distinct step.

In my approach, the messages are transferred directly to the PBX component
as a normal function of the async framework. There is code that processes
inbound socket data. But that code is generic (i.e. it doesnt know about
"telephony_message" types) and having completed a message it directs it
to the relevant party according to info retained in the framework.

Cheers.