From: "Boris" <boris@gtemail.net>
Rob Stewart wrote:
From: "Boris" <boris@gtemail.net>
How would the user level code know which insertion or extraction to repeat in an expression like this:
s << a << b << c << d;
Socket streams supporting non-blocking I/O would require the user to check the result of I/O operations. However this should already be done with today's std::iostreams. If s is eg. of type std::ofstream and a call to << fails you have the same problem, don't you?
Yes and no. When writing to a file, you can inspect its contents and determine what's missing. You can also delete it and rewrite it from the beginning. With sockets, you can't seek back to determine where you left off. Instead, clients must establish a protocol that permits resending a block of data, even if the receiver has had no problems reading data to that point. IOW, if a given message required more than one TCP block, the receiver will have read some number of blocks and will expect more to complete the current message. The protocol will have to recognize that the sender restarted the current message, throw away the currently read data (from the successful blocks), all because the sender couldn't figure out which insertion (<<) failed. Do you intend to impose that requirement on clients? Typically, when trying to do async I/O, one does one datum at a time in order to know when that datum is sent or not. Sending multiple data in a row before checking for success leads to the problem I desribed above. So, allowing streaming for async I/O creates problems because you can chain the insertions or extractions and only check the status after all have been attempted. Put another way, I don't think the two can be reconciled nicely. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;