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