Re: [boost] Help with a Sockets library?

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 
>      approach.

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.

George Heintzelman
georgeh_at_[hidden]