From: George A. Heintzelman (georgeh_at_[hidden])
Date: 2001-07-27 09:39:07
> Something like this was developed back in about 1994. It was called
> Sockets++ and if I rember correctly, it inheritted form iostream. At
> one time, a copy of it was shipped with ACE ( although not any longer
I am somewhat familiar with Sockets++; we looked into using it. There
were two real problems with it. First, it was based on the old iostream
libraries, not the templatized ones that finally made it into the
standard. Second, though it had some support for non-blocking streams,
it was rather painful to use. Simple timeouts were relatively easy to
do, but the kinds of things I needed to do -- finding out if a message
was complete, and if so returning it, otherwise returning without
sending the message -- were much harder.
If these two issues were to be fixed, I believe it would be a fine
starting point for boost's socket/non-blocking IO libraries; it is
non-intrusive, and the interface handles all of the bind/listen system
call orderings transparently.
> I believe that it did not perform as well or as predictablely as ACE's
Unfortunately, ACE is a very large package, doing many many different
things. I have heard good things about ACE (though I've never actually
used it), but my impression is that integrating it with legacy systems
such as the ones I have to deal with would be a formidable task. I have
a hard enough time getting boost accepted here at my workplace, and
boost takes great pains to be non-intrusive.
As far as performance -- I see no inherent reason why an
IOstreams-based approach would have performance difficulties, though
certainly we could look at any performance differences.
> It would probably be easist th achieve what you are after by reading
> into a vector < unsigned char >.
Of course -- and that is what I have done -- but it is precisely this
kind of user-level buffering I am trying to avoid.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk