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