On 4/12/05, Don G <dongryphon@yahoo.com> wrote:
I've posted a zip with an HTML file and an HPP file that describes an abstract way to interact with the network. It is intended as a medium level interface. By that I mean it is above the socket layer, but below buffering/proactor/reactor kinds of thinking. It is really a pure C++ way to interact with the primitive concepts of networking.
Overall it looks pretty nice. A few observations: * port_t should be unsigned short, not unsigned int * timeout constructors are inconsistent. One takes seconds + microseconds and one takes milliseconds, at least according to the names of the arguments. * I wouldn't call the type you pass to the network::new_{local,broadcast,loopback,}_address method a "url". It isn't one. Perhaps "address_specifier" would be better? I can imagine some sort of "stream factory" class with pluggable protocols (e.g. http, https, ftp, etc) that would take fully qualified URLs to create new streams, but in this case you're dealing with at most a hostname and port.
I believe the code recently posted by Michel André is complementary in the sense that it is a way to connect implementation details such as stream/datagram with how I/O blocking is performed. That said, there is a fundamental difference in what the user of the library would see and have to handle. It may just be me, but I am not a fan of the coupling created by explicitly connecting multiple I/O objects with a dispatcher. This is a tedious prospect. Especially when there are limits on the number of such connections a dispatcher can handle (such as 64-ish for Windows).
I'd contend that in general, an operating system supplied multiplexing facility will scale better than one that uses a thread to handle each connection. Without some sort of multiplexing facility, how do you know when a channel is ready for I/O? It seems that your proposal is to use a pool of threads to handle async/non-blocking operations, but I don't see any interfaces defined to control or manage these operations. Is that just TBD? Clearly Windows select and WFMO are not as scalable as UNIX select/poll/etc, but I'd contend that if one is writing a serious networking application for Windows, you are going to make use of *both* of these approaches (>1 instance of WFMO/select and thread pooling). In some cases, you may want to do this on UNIX too. I think the point I am trying to make is that there isn't necessarily one right answer. Pools of threads are good for some things, and I/O multiplexing facilities are good for some things. And in some cases, taken both together they are a good thing as well. -- Caleb Epstein caleb dot epstein at gmail dot com