Re: [boost] [Ann] socketstream library 0.7

From: Simon Richter (Simon.Richter_at_[hidden])
Date: 2005-06-09 17:35:55

Hi,

Caleb Epstein wrote:

>>>Please do!  Does either of the implementations offer an interface to
>>>the sockets at a lower level than iostreams though?
>>Mine doesn't, so far, as I haven't seen a need for it.

> I believe it is an absolute requirement for a C++ Sockets library.

Hrm, I have never missed being able to access files from a lower level
than iostreams so far. :-) I never do binary I/O directly in my
applications but always implement an inserter/extractor pair that uses
streambuf iterators, though.

iostreams' read()/write() should be enough for stream-based I/O, and for
datagrams I'd propose going through another step anyway (i.e. have a
separate stream class that does not derive from the standard iostreams
but rather allows inserting and extracting packets only.

What would be really needed in iostreams would be some sort of
transaction interface that would allow me to abort insertion and
extraction mid-way. It may be possible to emulate that using putback,
and I think this will be the way to go here.

> Well, I don't think it makes sense to implement iostreams on top of a
> non-blocking socket interface.  If a user wants to use "socketstreams"
> they can reasonably be forced to use a blocking I/O model.

This would be acceptable for the average client but inhibit writing
server code without resorting to C function calls, parsing messages into
stringstreams and going from there, at which point you already have two
parsers - one to determine whether the message is complete and can be
extracted, one to actually extract.

> Although the Boost.Iostreams library may make non-blocking doable.

With a little care, it can be done with the current iostreams library --
however the {i,o}stream_iterator classes will have to be exchanged by
transaction capable ones and there needs to be a way to distinguish
between end-of-stream and end-of-available data on a stream. While
iterators would go past-the-end in either case, an application needs to
know whether to restart afterwards. Fortunately, this can be added as a
stream-specific function.

What I currently cannot think of is how to make nonblocking streams go
bad() if an extraction fails because no more data is available and noone
took care to put back the already extracted characters.

> This should not preculde a different user or even another part of the
> same application from using a non-blocking socket interface at "layer
> 1".  IMHO of course.

Whether the sockets you have are blocking or nonblocking is determined
by whether there is a manager attached to them. If you use a manager,
you are expected to handle end-of-file conditions that aren't, by asking
the stream whether this is really EOF and resetting the stream state
accordingly. I can see no problem here.

> Proposed Socket Library Layers:
> http://thread.gmane.org/gmane.comp.lib.boost.devel/122484

This is more about the big picture, stacking more complex interfaces on
top of it. I think we should implement iostreams for sockets first, then
we can go on to implement the mighty httpwistream that will give you
"wchar_t"s, whatever the document encoding was. :-)

   Simon