Re: [boost] asio formal review begins

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-12-14 17:52:42

On Wed, 14 Dec 2005 17:31:22 -0500
Stefan Seefeld <seefeld_at_[hidden]> wrote:

> For me a 'socket class' is two things (let's ignore datagram sockets
> in this context): a way to create socket endpoints, as well as
> manipulate associated options, and on the other hand some means to
> read and write.

First, you can't ignore datagrams, as that is a large part of modern
networking, especially in large data distribution systems.  But, for the
sake of conversation...

> For the synchronous case I think this is nicely described by a
> streambuf / stream pair of interfaces. A 'socket_stream' class would
> allow to create socket endpoints, and set socket options.
> A socketbuf class would implement read and write operations.

I've looked at a ton of IOStream network implementations over the years.
 Two of my major problems with IOstreams for networking: error handling
and performance (followed closely by several other issues).  I've yet to
see anything close to reasonable.  For that matter, I've yet to see
anything implemented with the IOStreams that isn't a problem for
anything but the most simple applications.  As soon as I see IOStreams,
my antennae go crazy.  Sure, it's a nice concept...

I think it is appropriate to offer an IOStreams interface for those who
desire such an interface.  However, if that is the best way to use synch
sockets in boost, I won't go near it.

For many years, I have been in the business of very high performance,
highly distributed network applications, and my paranoia is well placed
;-)

> On the other hand, asynchronous I/O over sockets would be handled very
> differently. In fact, given that platforms provide quite different
> means to wait for readable data (say), I'm not even sure that the
> 'socket' concept should be discussed independently from the sync /
> async policy at all.

I can see your point.