[network] An RFC posted to the sandbox
Hi All, 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. In the proposal I posted, work is done by worker threads. User code interacts with these to do async/non-blocking operations (see the HTML for details). What is missing is the pure async library that would allow trivial marshalling of such callbacks back to a single thread. I will look at putting that piece together with usage examples in the next couple days to round out the interface proposal. I am curious to know what folks think about this approach. 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). Best, Don __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail
On Tue, 12 Apr 2005 07:41:34 -0700 (PDT), Don G <dongryphon@yahoo.com> wrote: []
I am curious to know what folks think about this approach.
Hi Don, I skimmed through you stuff. It confused me a lot. What kind of applications is that targeted for? For a heavy duty high performance server you don't want to use it, because the abstractions you provide do have a price, and I'm not sure about the quality of implementation. What you need when doing such a server is to stick close to the metal, not paying for (I'm pretty sure you know that) useless context switches, lock contention, memory allocations and data copies. One really don't care about Linux/Windoze portability for this kind of servers just because Windoze is not an option for it's poor network performance and inherent security breaches. For a simple portable application one would probably stick to BSD nonblocking sockets + select() or blocking sockets + threads. The resulting code size will probably close to that of the code using your stuff, but code transparency and complexity will be in favor of the former for sure. Aside from this, I'm rather skeptical about the library you are working on guys. IMO, the root of all problems and complexity is its intended portability. The target platforms' APIs are too different to make implementation efficient and usable for any kind serious network application. If M$ does not care about its network APIs portability, why would anyone else care about it? -- Maxim Yegorushkin
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
participants (3)
-
Caleb Epstein -
Don G -
Maxim Yegorushkin