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

From: Iain K. Hanson (ikh_at_[hidden])
Date: 2005-04-25 18:07:17

On Mon, Apr 25, 2005 at 11:45:06PM +0300, Boris wrote:
> 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.

Why do people think that just because you are using an iostream interface 
you can break the basic rules of TCP programming!!!

Using iostreams there must be a buffer ( usually a streambuf ). The buffer size
*must* be equal tp the MSS / path MTU.

As the application protocol writter you have to know how much you have written to
the buffer *at all times* and you must know when an overflow / flush will happen.

Errors can *only* happen when the buffer writes to the socket ( overflow/flush )
therefore if a programmer does his/her job correctly there will not be multiple
operator << traversing and overflow boundary. This is irrespective of sync/async.

Braek the rules in network programming and you are up the proverbial creek 
without a paddle. And C++ can not protect you against all kinds of errors. We
can only make it saffer, not safe.

/ikh>