Caleb Epstein wrote:
I believe it is an absolute requirement for a C++ Sockets library.
I believe the only absolute requirement for a C++ networking library is an implementation of the standard IOStream interface, and whatever support stuff is needed to make it work (like addressing and resolving names). The streambuf interface provides everything a typical "client" object requires for sending and receiving data. I suspect most would settle their needs if a "network_archive" were implemented for boost::serialization. The most network intensive application we maintain at work certainly would.
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
IOStreams are merely a formatting layer over the stream represented by a streambuf. And streambufs are merely a buffering strategy over some form of stream of data. In the end, we have the same kinds of operations we always had with read() and write(). The only difficulty of implementing a non-blocking streambuf is deciding how to return such state information to the client code; this decision would then allow or deny this or that kinds of programming idioms. This information is sometimes returned as an EWOULDBLOCK error, sometimes returned as a zero amount of bytes processed, by the socket primitives. Errors returned by streambuf are captured by the formatting object and translated to eofbit, failbit and/or errorbit being set, which might cause an exception to be thrown. At the streambuf layer, it would be possible to reserve some value of int_type that's not a possible value for char_type and call that traits_type::would_block(), so to speak. But the formatting formatting operators return references to themselves to allow for such nifty idioms as: iostream io; string s; while (io >> s) // Work, work, work But generally non-blocking operations aren't used standalone like that, but together with a poller service to avoid blocking on idle streams when there are too many streams lying around; this might make the problem moot, as we may just contain the non-blocking behaviour inside such a poller service. This is the approach I'll try, but I will probably not do it before thinking of some kind of application that would exercise this. -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business