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

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.

Boris