On 6/9/05, Simon Richter <Simon.Richter@hogyros.de> wrote:
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.
I personally prefer to use lower-level read/write semantics with sockets and handle would-block conditions etc in my own code.
This is the main reason why the manager code is not implemented yet: I am still trying to think of a portable way to reset the read position if an extractor fails due to no more data being available presently.
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. Although the Boost.Iostreams library may make non-blocking doable. 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. Proposed Socket Library Layers: http://thread.gmane.org/gmane.comp.lib.boost.devel/122484 -- Caleb Epstein caleb dot epstein at gmail dot com