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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-04-25 11:52:09

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?

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_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;