Re: [boost] Sockets: proposal for a library design

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2005-03-11 15:25:24

Boris wrote:
> I updated the Wiki pages for a net library at 
> http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostNet. 
> After collecting all the information I found at the Wiki pages for the 
> socket and multiplexing library I try to explain how a net library should 
> basically look like. The proposal includes various I/O models and is based 
> on I/O streams.

I am curious why it is necessary to model all four of the socket types
you enumerated.  Do you think that there will be users who require each
of these models?

One potiential troublesome point is that as the interface becomes more
expressive in this manner, there will be more problems for platforms
that don't have good support for one of these models.

I'm also concerned that a library with this sort of flexability,
including the ability to switch models at runtime, may be very difficult
to implement correctly.

Besides that, its also been pointed out that streambuf makes a fairly
awful basis for a socket class.  In my work with networked programs,
I've found that a streambuf and the formatters quite often do not add
anything positive to the design at all.

I'd like to see a socket class with core functions that are fairly
agnostic to standard iostreams, for the very common case when they are
not helpful.

This description also seems to focus entirely on the mechanics of
reading and writing itself, which really is not at all specific to
sockets in particular.  Everyone always seems to get to caught up on
this specific issue, and neglect the other dozens of important issues in
working with sockets.  For example, I'd like to see an interface that
has a very reasonable way of handling different sorts of sockets, that
doesn't zoom in one "one true socket paradigm" such as IPv4 TCP, with
UDP support hacked in somewhere, and no support for any other protocols.

Personally, I don't think its valuable in the slightest for Boost to
include yet another low quality TCP in iostreams library.

Aaron W. LaFramboise