Re: [boost] (Another) socket streams library

From: Nathan Myers (ncm_at_[hidden])
Date: 2005-05-15 15:37:33

Aaron W. LaFramboise wrote:
> Nathan Myers wrote:
> 
> > What do we need from this boost-nonblocking-socket-streambuf? At
> > minimum, we need to see what it has in its buffer (i.e.
> > begin()/end()),
> > and we need for that buffer to grow as large as necessary until we
> > can hand it to some library to be drained. (Maybe it's backed by a
> > std::deque<char>.) Beyond that, it would be nice for it to abstract
> > the calls to open and jimmy the socket. None of this is rocket
> > science.
> 
> I am concerned that this is only compatible with algorithms where the
> total amount of data to be read in a single operation is small enough to
> fit into a reasonable amount of buffer memory, and that this encourages
> dubious code by having very different interfaces for the very similar
> operations of /examining the data/ and /examining the data and removing
> the data from the buffer/.
> 
> What do you think about an alternate scheme that requires the parser to
> be aware of the non-blocking interface of a stream? Add a would-block
> condition to the streambuf that is like EOF except it just means you're
> out of data, and add a mechanism for unlimited (and efficient)
> push-backs. Perhaps the istream might translate this into a blockbit
> flag and a mechanism to do this rollback automatically when extraction
> fails due to blockbit. 

This is a good idea, except:

1. Unlimited pushback implies unlimited buffering too.

2. Pushback of any kind is a nasty hack, and inherently inefficient.
   Better: Make pubseek() work, but every time you call it, it is 
   allowed to throw away everything _before_ the target position.  
   The first seek (to "here") gets the position; the second seek 
   goes back to it.  (This also implies unlimited buffering.)

3. To do good streamed, nonblocking parsing, you really need a state
   machine object.  Such a parser probably should work on an Iterator 
   instead of a stream or streambuf.  Then, when you find you have 
   input available, you just get it and hand what you got to the 
   parser as a pair of iterators.  The parser tells you when it
   has something, and you tell the parser when EOF happens.

4. It wouldn't work.  Who will write istream code to read your odd 
   stream?  If they were willing to do that, they might as well use 
   a socket (-object) directly.  As I see it the only reason to talk 
   about this at all is to allow _existing_ istream code to be used 
   on a nonblocking socket without resorting to copying.  (That is 
   not to say that I, personally, have had a need for such a thing 
   -- else I would have cobbled it together already.)

Nathan Myers
ncm_at_[hidden]