Re: [boost] sockets library

From: Fisher; Damien Kaine (dfisher_at_[hidden])
Date: 2001-12-19 19:49:54

To me, an important design consideration when designing a sockets library
is whether you are going for allowing super-scaleable, super-efficient
operations, or a nice easy to use interface.

If the latter, I think iostreams would be fairly acceptable, although in
ever project I've ever worked on "human readable" protocols were only the
first step, and later replaced by more efficient protocols.

However, sockets get fairly ugly beyond simple blocking send() and
recv().  Just consider, for example, the options you have for implementing
a server on the Windows platform (this is by no means exhaustive or
correct :) ):

1.)  Blocking send(), recv(), with 1 thread per client - ugh ** 2.
2.)  select() - ugh.
3.)  Overlapped I/O.
4.)  I/O completion ports, using AcceptEx, scatter gather I/O, etc etc.

I invariably use (4), because I have written libraries for them, which
work well, but are completely non-portable (I once saw a patch for the
linux kernel which used i/o completion ports, but I think it was knocked
back because linux has other ways of doing such things - which are outside
what I know, unfortunately).

What I am trying to point out is that for any realistic server or client,
which is handling a fairly large amount of data or connections or both
(and on today's broadband connections, even clients can sometimes be
required to handle large amounts of data), implementations can become
non-trivial quickly, and I suspect in a non-portable fashion.  I
really don't know if a socket library could be designed which is platform
independent, and which I would find acceptable (if it was, it would
probably be tightly coupled with boost::threads).  That's a task I'll
leave for the implementer :-P.

However, I can definitely see a need for a "simple" socket library built
on top of BSD sockets.  As long as it is clear from the outset that that
is what is being designed.

I should emphasise I have NFI about sockets on Unix beyond basic BSD
socket manipulation.