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