Boost logo

Boost :

From: Boris (boris_at_[hidden])
Date: 2005-04-25 15:45:06

Rob Stewart wrote:
> From: "Boris" <boris_at_[hidden]>
>> Rob Stewart wrote:
>>> From: "Boris" <boris_at_[hidden]>
>>> 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?

I was under the false assumption that "s << a" either completes successfully
or fails completely. But you are right: If a part of object a is sent we
don't know. Thanks for jumping in! I agree now that socket streams can only
support blocking I/O.


Boost list run by bdawes at, gregod at, cpdaniel at, john at