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@gtemail.net> To: <boost@lists.boost.org> 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.