Re: [boost] [Ann] socketstream library 0.7

From: Pedro Lamarão (pedro.lamarao_at_[hidden])
Date: 2005-06-09 17:27:28

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