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

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-04-25 17:15:15

> From: "Boris" <boris_at_[hidden]>
> 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.

It is possible to get the condition you describe, too, But my
example was a typical insertion expression in which multiple
insertions are done on one line and the result isn't checked
until after:

   s << a << b << c << d;

Ignoring the possibility that any of those insertions only
partially completed because of UDT insertion operators, for
example, you don't know which insertion (of a, b, c, or d)
failed if the result of the expression is false (i.e., if
s.good() is false).

Note that you can use unformatted input/output functions on
streams.  Those could reasonably offer async I/O since they
effectively just forward to the underlying streambuf for I/O.
However, you still have to figure out how to report EWOULDBLOCK.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;