[network] Boost.Network proposal v0.3
Fellow Boosters, this is an update on my proposal for (the beggining of?) a Boost.Network library, located in the Sandbox. I consider it feature complete for a 1.0 milestone; the features being: *) IOStreams classes, fully buffered *) A listener class *) A wrapper for the name resolution service *) A type to store addresses The missing pieces being: *) Complete the copy constructores and assignment operators of the generic_address class. *) Implement optimized xsputn() and xsgetn() in the stream buffer. *) Implement setbuf() in the stream buffer. *) Documentation (never enough) The above list is what I intend to polish up for a formal proposal. This is the TODO list for a next version: *) Address types specific for IPv4 and IPv6, with input operators. *) A formatter output operator for generic address types based on the name resolution service. *) Resolver options and manipulators for the above output operator. *) Code conversion in the stream buffer. *) A poller class. *) Wrapper for sendfile/TransmitFile. *) Implement showmanyc() and perhaps putbackfail() in the stream buffer. With a proper poller class I believe most people's desires for non-blocking operation would be satisfied. I'm going out of town on vacations for some days, so things are going to stall for a while. I hope to complete all tasks soon after Boost 1.33 is released and a new review cycle starts. -- Pedro Lamarão
Pedro Lamarão wrote:
The missing pieces being:
Asynchronous socket support: Finding a way to represent asynchronosity, that works with diverse coding styles, meshes with existing interfaces, and doesn't monopolize control flow away from foreign components, is the most important feature needed for a standards-track sockets proposal. Please do not consider submitting this library for review without this. I expect that the work of creating this interface, in a form that addresses everyone's diverse needs, will dwarf the amount of effort required to create a synchronous socket streambuf. This is not a feature that can be tacked on later: it is essential to the design. Aaron W. LaFramboise
Aaron W. LaFramboise wrote:
Asynchronous socket support: Finding a way to represent asynchronosity, that works with diverse coding styles, meshes with existing interfaces, and doesn't monopolize control flow away from foreign components, is the most important feature needed for a standards-track sockets proposal.
Please do not consider submitting this library for review without this. I expect that the work of creating this interface, in a form that addresses everyone's diverse needs, will dwarf the amount of effort required to create a synchronous socket streambuf. This is not a feature that can be tacked on later: it is essential to the design.
There are many networking applications where synchronous operation is quite suficient. Most of these can use threading to deal with concurrent connections satisfactorily. I don't think it's particularly useful to hold a library that fulfills these needs in order to achieve the holy grail of C++ IO. One thing at a time. As discussed before, if it makes everyone more comfortable, the name "Boost.Network" can be saved for a more powerful yet-to-come library. -- Pedro Lamarão
Pedro Lamarão wrote:
Aaron W. LaFramboise wrote:
Asynchronous socket support: Finding a way to represent asynchronosity, that works with diverse coding styles, meshes with existing interfaces, and doesn't monopolize control flow away from foreign components, is the most important feature needed for a standards-track sockets proposal.
Please do not consider submitting this library for review without this. I expect that the work of creating this interface, in a form that addresses everyone's diverse needs, will dwarf the amount of effort required to create a synchronous socket streambuf. This is not a feature that can be tacked on later: it is essential to the design.
There are many networking applications where synchronous operation is quite suficient. Most of these can use threading to deal with concurrent connections satisfactorily.
I don't think it's particularly useful to hold a library that fulfills these needs in order to achieve the holy grail of C++ IO. One thing at a time.
Any networking library which does not have non-blocking asynchronous support for network I/O is, IMO, doomed to general non-use. But go ahead and create one if you like and see how many end-users adopt it for their networking needs.
Edward Diener wrote:
Pedro Lamarão wrote:
Aaron W. LaFramboise wrote:
Asynchronous socket support: Finding a way to represent asynchronosity, that works with diverse coding styles, meshes with existing interfaces, and doesn't monopolize control flow away from foreign components, is the most important feature needed for a standards-track sockets proposal.
Please do not consider submitting this library for review without this. I expect that the work of creating this interface, in a form that addresses everyone's diverse needs, will dwarf the amount of effort required to create a synchronous socket streambuf. This is not a feature that can be tacked on later: it is essential to the design.
There are many networking applications where synchronous operation is quite suficient. Most of these can use threading to deal with concurrent connections satisfactorily.
I don't think it's particularly useful to hold a library that fulfills these needs in order to achieve the holy grail of C++ IO. One thing at a time.
Any networking library which does not have non-blocking asynchronous support for network I/O is, IMO, doomed to general non-use. But go ahead and create one if you like and see how many end-users adopt it for their networking needs.
I'm sincerely fascinated by this comment, which I feel represent how almost everyone in these networking threads feel. I must be absolutely ignorant in what constitutes a performant networking application, if multiple threads blocking on IO is a design doomed to general non-use by those writing multi-session applications. Can you explain to me what is fundamentally wrong with this model, and how the use of asynchronous primitives or the non-blocking mode is so vastly superior? I would sincerely like to know, because I've been writing those for some time, and, though our clients aren't complaining, perhaps I could be delivering more. -- Pedro Lamarão
----- Original Message ----- From: "Pedro Lamarão" <pedro.lamarao@mndfck.org> To: <boost@lists.boost.org>
Any networking library which does not have non-blocking asynchronous support for network I/O is, IMO, doomed to general non-use. But go ahead and create one if you like and see how many end-users adopt it for their networking needs.
I'm sincerely fascinated by this comment, which I feel represent how almost everyone in these networking threads feel.
I must be absolutely ignorant in what constitutes a performant networking application, if multiple threads blocking on IO is a design doomed to general non-use by those writing multi-session applications.
"performant"? If "multiple threads blocking on IO" means "thread-per-session" then that is not scalable to some of the larger applications.
Can you explain to me what is fundamentally wrong with this model, and how the use of asynchronous primitives or the non-blocking mode is so vastly superior?
There's nothing "fundamentally wrong" with it. As you say, it works. Non-blocking also "works" but this means different things each time. IMO the entire process of software development (design through to maintenance) is affected by whether a selected network library is blocking or non-blocking. To generalize; blocking libraries seem to constrain the process while non-blocking provides so much freedom that it can bite. The above paragrah is about the long term significance of non-blocking vs blocking. I believe you are also facing the issue of library (de-)composition; if you ultimately want to provide both a blocking and non-blocking API it is less difficult to imagine a non-blocking API over a blocking API than the other way around. A library developed with no regard to non-blocking will be an island; it will force the development of a separate non-blocking network library.Whether that arrangement is truly sub-optimal? I dont know. For me at least, a non-blocking network library is the "pot of gold". Its what my more ambitious projects are screaming out for and what would make my code so much more appealing. Which doesnt mean to say that I dont write several blocking test programs a month. Scott.
I would sincerely like to know, because I've been writing those for some time, and, though our clients aren't complaining, perhaps I could be delivering more.
-- Pedro Lamarão
_______________________________________________ Unsubscribe & other changes:
Edward Diener wrote:
Any networking library which does not have non-blocking asynchronous support for network I/O is, IMO, doomed to general non-use.
For what it's worth, I completely agree. Scott Woods wrote:
if you ultimately want to provide both a blocking and non-blocking API it is less difficult to imagine a non-blocking API over a blocking API than the other way around.
I take it you meant the opposite? A non-blocking API can be trivially wrapped to block, but the other way round doesn't work too well.
On 04 Aug 2005 16:59:36 +0200, Peter Simons <simons@cryp.to> wrote:
if you ultimately want to provide both a blocking and non-blocking API it is less difficult to imagine a non-blocking API over a blocking API than the other way around.
I take it you meant the opposite? A non-blocking API can be trivially wrapped to block, but the other way round doesn't work too well.
For what I understood, that's exactly what he said. regards -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
On 8/3/05, Pedro Lamarão <pedro.lamarao@mndfck.org> wrote:
I must be absolutely ignorant in what constitutes a performant networking application, if multiple threads blocking on IO is a design doomed to general non-use by those writing multi-session applications.
Can you explain to me what is fundamentally wrong with this model, and how the use of asynchronous primitives or the non-blocking mode is so vastly superior?
Asynchronous scales a lot better, if you're putting each session on a thread it wont be able to handle too many connections reliably. With asynchronous, completion ports or select/poll you're able to handle multi-session without requiring more threads. That way you can have one thread per processor and that way not kill the performance with context switches.
I would sincerely like to know, because I've been writing those for some time, and, though our clients aren't complaining, perhaps I could be delivering more.
Probably your application doesnt have to handle too many connections at the same time.
-- Pedro Lamarão
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."
participants (6)
-
Aaron W. LaFramboise -
Edward Diener -
Felipe Magno de Almeida -
Pedro Lamarão -
Peter Simons -
Scott Woods