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
>> 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
> 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
> 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
> 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.
> 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!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk