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

From: Boris (boris_at_[hidden])
Date: 2005-03-11 17:41:53

Aaron W. LaFramboise wrote:
> 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?

Which I/O model(s) would you like to see dropped?

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

AFAIK there is at least one implementation possible of each I/O model on 
Windows and Unix plattforms. What platform(s) are you thinking about?

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

I agree. However I would like to design a library with an optimistic view. I 
am sure problems will pop up everywhere as we proceed. But then we have good 
reasons at least why the library design must be changed.

> 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 have doubts myself about streambuf and I/O streams. However the network 
libraries I built until now were no general purpose libraries for a standard 
but tailored for a specific need. As we have a general I/O library in C++ 
lots of programmers are familiar with I feel like we need some strong 
arguments why a network library which also does I/O is *not* built on I/O 
streams.

> 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

I started with reading and writing in regard of I/O models as I think there 
are very difficult problems we face, influence the design of the whole 
network library and therefore must be discussed first. I agree that a lot of 
other things you would expect in a network library are still missing.

> that
> has a very reasonable way of handling different sorts of sockets, that

If we start now creating several classes for different sorts of sockets (and 
I agree that this might be useful) and talk about I/O models later our 
solution to the I/O model problem might influence the design of our socket 
classes. The interface of the socket class or socket classes strongly 
depends on the I/O models we would like to support.

> 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

UDP is no stream and therefore not based on I/O streams. Supporting 
connectionless protocols like UDP is much easier to implement.

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

Do you have any URLs for me to understand better why a design based on I/O 
streams automatically means low quality TCP support?

Thanks for your comments so far!

Boris