surveying async network io libraries
Hi, Pardon my high level focus as I am new to the list. I have read all the multiple threads on this topic and I only want to confirm understanding of what libraries can be used now or in a few months, before a future boost library is available. Authors please jump to provide info on your release plans (if possible). I define the library as a c++ async network io library (at least linux ready now but multi-platform in the future) at the connector / acceptor level (or higher but never at the sockets level) that can be combined in different concurrency models (e.g. single-threaded or multi-threaded where the async network io can run in one or multiple threads). I'll just list a brief pro/con list for the 3 libraries I've found so far nanostreamer (downloaded from the boost vault) ========== pros - good introductory article.pdf - designed to make best use of c++ and boost (my newbie opinion!) - real world code examples, e.g. http server (although not fully developed) cons - no async network io available yet although it is planned (see event queue ext) asio (asio.sf.net) === pros - async network io ready (linux epoll as of 0.31) cons - basic real world code examples (but no http examples) - does not use boost threads netiphany (netiphany.sf.net and boost vault) ======= pros - simple usage (see rfc doc in the vault archive, by Don G) - focused on async network io (not sure how it can be combined with threads) cons - no implementation distributed yet (although mentioned and partially shown in the sf docs) Note that I've not included sockets wrappers or libraries that will not provide an async network io solution in the short term. Also worth checking the scheduler library in cryp.to and the CUJ dec 2002 article on a templated library for fast multiplexing although both of those don't seem to have active development. Thanks and regards Jose
Hi Jose, I have a couple of comments on asio's cons, as you listed them... --- Jose <jmalv04@gmail.com> wrote:
asio (asio.sf.net) ===
pros - async network io ready (linux epoll as of 0.31)
cons - basic real world code examples (but no http examples)
I can say that asio has been successfully used to develop HTTP servers and clients (as well as many other protocol implementations such as XMPP and SOCKS). Of course, that doesn't really help if you are looking for an example! I'd love to add to the examples included with the library, but unfortunately paid work takes priority.
- does not use boost threads
asio does not use boost threads for any internally created threads, and includes its own thread wrapper class, because my customers required a header-file-only library. However, you are free (and I would encourage you) to use boost threads to invoke the demuxer's run function from a thread, e.g. asio::demuxer d; boost::thread th(boost::bind(&asio::demuxer::run, &d)); ... th.join(); Furthermore, the Linux/UNIX implementation of asio does not create *any* internal threads, so the only threads in your process would be ones you create using boost (or whatever other method you prefer). Cheers, Chris
Thank you for clarifying. If the goal for your library is to improve it and get a lot of users then I think the http examples are needed, even before adding more features. Probably 80% of networking code today has http in it. If the goal is not that one, then it's probably a traditional corporate project driven by other goals. I just want to know the goals before investing lots of time using your library or providing feedback It's a pity that there is not a widely used c++ net library and ACE is not a practical solution for many of the boost users. I just hope that one of these libraries here or a combination of all of them will get some traction and we can all benefit. This obviously requires some additional effort from the main library authors but responding to potential users makes the library move forward. Unfortunately writing good examples is not something that a new library user like me can do easily. On 8/10/05, Christopher Kohlhoff <chris@kohlhoff.com> wrote:
Hi Jose,
I have a couple of comments on asio's cons, as you listed them...
--- Jose <jmalv04@gmail.com> wrote:
asio (asio.sf.net) ===
pros - async network io ready (linux epoll as of 0.31)
cons - basic real world code examples (but no http examples)
I can say that asio has been successfully used to develop HTTP servers and clients (as well as many other protocol implementations such as XMPP and SOCKS). Of course, that doesn't really help if you are looking for an example! I'd love to add to the examples included with the library, but unfortunately paid work takes priority.
- does not use boost threads
asio does not use boost threads for any internally created threads, and includes its own thread wrapper class, because my customers required a header-file-only library.
However, you are free (and I would encourage you) to use boost threads to invoke the demuxer's run function from a thread, e.g.
asio::demuxer d; boost::thread th(boost::bind(&asio::demuxer::run, &d)); ... th.join();
Furthermore, the Linux/UNIX implementation of asio does not create *any* internal threads, so the only threads in your process would be ones you create using boost (or whatever other method you prefer).
Cheers, Chris _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Jose writes:
Also worth checking the scheduler library in cryp.to [although it doesn't] seem to have active development.
I still maintain the library -- it's just that there isn't much to do anymore. To be considered as a Boost component, the Scheduler class would probably need to be made more generic. (Right now, the use of poll(2) is hard-coded, for example.) I'm open to making those changes, it's just that I didn't have the need to do it so far. If there is any interest, I'll gladly release the code under an all-permissive license instead of the GPL. I wanted to do that for a while anyway. Peter
See my previous response. I think a well thought out boost scheduler/multiplexor module is needed. I would just focus on async network io in linux (preferably using epoll). Networking is one area where boost should probably have separate platform solutions so that best performance and elegance are not compromised. On top of that, having an acceptor and connector implementation with basic http examples would go a long way towards advancing in the right direction. If you plan to do this then I would gladly use it and provide feedback. I would wait first for more opinions. I am coming from the newbie boost user perspective that wants to build networking apps easily and doesn't need ACE. On 10 Aug 2005 19:26:15 +0200, Peter Simons <simons@cryp.to> wrote:
Jose writes:
Also worth checking the scheduler library in cryp.to [although it doesn't] seem to have active development.
I still maintain the library -- it's just that there isn't much to do anymore. To be considered as a Boost component, the Scheduler class would probably need to be made more generic. (Right now, the use of poll(2) is hard-coded, for example.) I'm open to making those changes, it's just that I didn't have the need to do it so far. If there is any interest, I'll gladly release the code under an all-permissive license instead of the GPL. I wanted to do that for a while anyway.
Peter
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 8/10/05, Jose <jmalv04@gmail.com> wrote:
See my previous response. I think a well thought out boost scheduler/multiplexor module is needed.
The asio library really looks quite nice. It appears simple to use, is 100% header-based, doesn't require the use of threads, and uses the most scalable event demultiplexor supplied by the OS (epoll on Linux in the 0.3x version and IOCP on Windows). Its a very nice little library! Thanks for linking to it. I think I'm in love :-) That it doesn't use Boost.Threads itself should not be considered a strike against it. Nothing prevents its use in applications using Boost.Threads, as the asio maintainer stated in his earlier reply.
I would just focus on async network io in linux (preferably using epoll). Networking is one area where boost should probably have separate platform solutions so that best performance and elegance are not compromised.
On top of that, having an acceptor and connector implementation with basic http examples would go a long way towards advancing in the right direction.
What do you consider "the right direction"? Aside from the lack of higher-level examples, what do you think asio is lacking?
If you plan to do this then I would gladly use it and provide feedback. I would wait first for more opinions. I am coming from the newbie boost user perspective that wants to build networking apps easily and doesn't need ACE.
ACE is indeed overkill for *just* networking, but it is battle-tested, feature-rich, fast, and *very* portable. Like it or not, many of the patterns implemented in ACE are must-haves once you have a nice networking library and want to start writing more complex applications (logging, threads, synchronization primitives, message queues, active objects, etc.). Boost provides a number of these, but the sheer breadth, depth, and maturity of ACE makes for a very compelling library. -- Caleb Epstein caleb dot epstein at gmail dot com
On 8/11/05, Caleb Epstein <caleb.epstein@gmail.com> wrote:
On 8/10/05, Jose <jmalv04@gmail.com> wrote:
On top of that, having an acceptor and connector implementation with basic http examples would go a long way towards advancing in the right direction.
What do you consider "the right direction"? Aside from the lack of higher-level examples, what do you think asio is lacking?
From a newbie perspective, the examples are what attracts me to a
"the right direction" would be having one or two net libraries that are widely used by boost users so that they are a de facto standard here and we all benefit from that. I don't like reinventing the wheel ! library. If the example are practical/useful and real world then I want to use it.
If you plan to do this then I would gladly use it and provide feedback. I would wait first for more opinions. I am coming from the newbie boost user perspective that wants to build networking apps easily and doesn't need ACE.
ACE is indeed overkill for *just* networking, but it is battle-tested, feature-rich, fast, and *very* portable. Like it or not, many of the patterns implemented in ACE are must-haves once you have a nice networking library and want to start writing more complex applications (logging, threads, synchronization primitives, message queues, active objects, etc.). Boost provides a number of these, but the sheer breadth, depth, and maturity of ACE makes for a very compelling library.
Yes, but I think many boost users are looking for something simpler (based on the many networking threads written) that leverages other boost libraries as well.
"Jose" <jmalv04@gmail.com> wrote in message news:2084b47d05081100274a4988b3@mail.gmail.com...
On 8/11/05, Caleb Epstein <caleb.epstein@gmail.com> wrote:
On 8/10/05, Jose <jmalv04@gmail.com> wrote:
ACE is indeed overkill for *just* networking, but it is battle-tested, feature-rich, fast, and *very* portable. Like it or not, many of the patterns implemented in ACE are must-haves once you have a nice networking library and want to start writing more complex applications (logging, threads, synchronization primitives, message queues, active objects, etc.). Boost provides a number of these, but the sheer breadth, depth, and maturity of ACE makes for a very compelling library.
Yes, but I think many boost users are looking for something simpler (based on the many networking threads written) that leverages other boost libraries as well.
Also, Boost users are looking for something that plays well with the C++ Standard Library and TR1. ACE goes its own way. For example, ACE directory iterators aren't anything like STL iterators. That makes ACE less attractive to some users. --Beman
On 8/11/05, Beman Dawes <bdawes@acm.org> wrote:
ACE goes its own way.
Indeed. Thats one of the biggest knocks on ACE. It is difficult if not impossible to cherry-pick the functionality you need without pulling in the entirety of it. It is more of an Application Framework that way. -- Caleb Epstein caleb dot epstein at gmail dot com
ACE is indeed overkill for *just* networking, but it is battle-tested, feature-rich, fast, and *very* portable. ... Yes, but I think many boost users are looking for something simpler as well. ....
Also, Boost users are looking for something that plays well with the C++ Standard Library and TR1. ACE goes its own way. For example, ACE directory iterators aren't anything like STL iterators. That makes ACE less attractive to some users.
Yes, definitely! ACE is an excellent framework, but was designed and implemented for an early 1990's average C++ / OO programmer mentality. I'm assuming much of that was due to when ACE was originally designed, and part of it was due to supporting many "flavors" of C++ (and the standard library) during the mid 90's. I've been using ACE heavily for over a year now, and my list of pros and cons: Pros: o Support for a very large number of platforms o Excellent and powerful implementation of many useful networking related patterns o Nicely extensible framework, for many purposes o Covers a lot of useful, practical functionality o Generally well tested, robust Cons: o The C++ design and usage is not modern, which has many far-reaching implications - no interoperability with standard library, interface design is affected (e.g. it was designed to not use exceptions, resulting in "two stage object construction", in-out parameters with int error returns, etc), use of inheritance where templates would be more suitable (in many places). o The documentation is either too high-level, or not complete. The books written on ACE cover the architecture and general usage very well, but (obviously) can't cover every detail or use case. The Doxygen is useful in some places, and totally useless in others (here's an example I just looked at - "length() - get the length of the message; "size() - get the number of bytes in the top-level <Message_Block>", both of which are separate and distinct, and only understandable from reading the books). o Despite my reluctance to read code, sometimes the only way I've been able to understand what was going on (and what was not working right) was to read the code. Well designed libraries should rarely (or never) require reading the implementation code to understand semantics. o There is not always a clear separation between what is extensible and should be customized by the application / user, and what is not (partly a documentation issue, partly a design issue). o There are too many methods that provide access to internals - i.e. not enough logical encapsulation. There's probably a good reason for each one, but the result is a multitude of methods on almost all classes, many of which have no obvious and direct use. I'm very much looking forward to a well-designed event multiplexor and a set of lower-level network / socket interfaces in Boost. I've offered (and am still offering) to assist within the constraints of my time, either on implementation (although I can only provide limited OS expertise), or general design (I can probably offer more help here). It's good to see more and more momentum and actual offerings start to appear in this realm ... Cliff
So, Christopher, not to put too fine a point on it, but do you plan to submit your library for inclusion in Boost? -- Dave Abrahams Boost Consulting www.boost-consulting.com
I also think the asio library holds much promise and is quite close to many of the ideas we have discussed before. Although I'm not to found of the header only idea, since I've been bitten by bad headers some times ;), especially in the realms of networking and database access for some reason. /Michel
"Caleb Epstein" <caleb.epstein@gmail.com> wrote in message news:989aceac05081017387d79aa29@mail.gmail.com...
On 8/10/05, Jose <jmalv04@gmail.com> wrote:
See my previous response. I think a well thought out boost scheduler/multiplexor module is needed.
The asio library really looks quite nice. It appears simple to use, is 100% header-based, doesn't require the use of threads, and uses the most scalable event demultiplexor supplied by the OS (epoll on Linux in the 0.3x version and IOCP on Windows). Its a very nice little library! Thanks for linking to it. I think I'm in love :-)
Are you looking at v0.2.0 or v0.3.2? I'm unable to extract the latter on windows. Are there zip files available. Thanks, Jeff
Hi Jeff, --- Jeff Flinn <TriumphSprint2000@hotmail.com> wrote:
Are you looking at v0.2.0 or v0.3.2? I'm unable to extract the latter on windows. Are there zip files available.
I just created a zip file for 0.3.2. You can find it at: https://sourceforge.net/project/showfiles.php?group_id=122478 Let me know if you have any other problems with it. Cheers, Chris
I forgot to add to the list giallo.sourceforge.net The project implements proactor and reactor patterns but it's only available via CVS The new list (in order of package and implementation availability) is: * asio.sf.net * nanostreamer (via boost vault) * giallo.sf.net (via CVS) * netiphany.sf.net (only base class) So far only the asio library author has commented on this thread. On 8/12/05, Christopher Kohlhoff <chris@kohlhoff.com> wrote:
Hi Jeff,
--- Jeff Flinn <TriumphSprint2000@hotmail.com> wrote:
Are you looking at v0.2.0 or v0.3.2? I'm unable to extract the latter on windows. Are there zip files available.
I just created a zip file for 0.3.2. You can find it at:
https://sourceforge.net/project/showfiles.php?group_id=122478
Let me know if you have any other problems with it.
Cheers, Chris _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Christopher Kohlhoff" <chris@kohlhoff.com> wrote in message news:20050811223559.18901.qmail@web32601.mail.mud.yahoo.com...
Hi Jeff,
--- Jeff Flinn <TriumphSprint2000@hotmail.com> wrote:
Are you looking at v0.2.0 or v0.3.2? I'm unable to extract the latter on windows. Are there zip files available.
I just created a zip file for 0.3.2. You can find it at:
https://sourceforge.net/project/showfiles.php?group_id=122478
Thanks, I downloaded it and will take a look. Jeff Flinn
Jose writes:
I think a well thought out boost scheduler/multiplexor module is needed.
So do I. It would be very nice to have an I/O scheduler in Boost. All that other networking stuff is just sugar coating, IMHO. Personally, find working with read(), write(), and plain plain file descriptors to be much simpler than using any of those fancy iostream classes.
I would just focus on async network io in linux (preferably using epoll).
I believe that a good API could hide the underlying scheduling mechanism provided by the OS. A neat example would be this library: http://www.monkey.org/~provos/libevent/ It's portable across various Unices and Windows, and does provide a very clean abstraction of the thing we generally know as poll().
Networking is one area where boost should probably have separate platform solutions so that best performance and elegance are not compromised.
Although I agree that performance very important, it is my experience that the percentage of time spent in the scheduling parts of an I/O-bound application is rather miniscule. It doesn't really matter whether you maintain your poll() array with zero copies all the time, or whether you use epoll(), /dev/poll, kqueue(), or select(). These things may make a difference in benchmarks, but not in real-life applications.
On top of that, having an acceptor and connector implementation with basic http examples would go a long way towards advancing in the right direction.
No problem: http://cryp.to/mini-httpd/ http://cryp.to/mini-httpd/mini-httpd-1.0.tar.gz
If you plan to do this then I would gladly use it and provide feedback.
What I could definitely do is to get the source code I have right now checked into the Boost sandbox under an appropriate license, then we'll see where it goes from there. ;-) Peter
On 11 Aug 2005 10:38:00 +0200, Peter Simons <simons@cryp.to> wrote:
Jose writes:
I think a well thought out boost scheduler/multiplexor module is needed.
So do I. It would be very nice to have an I/O scheduler in Boost. All that other networking stuff is just sugar coating, IMHO. Personally, find working with read(), write(), and plain plain file descriptors to be much simpler than using any of those fancy iostream classes.
I'd like to see a pros/cons comparison of both approaches. I don't have enough experience to comment on this. Maybe this is a case were both approaches should be provided.
I believe that a good API could hide the underlying scheduling mechanism provided by the OS. A neat example would be this library:
http://www.monkey.org/~provos/libevent/
It's portable across various Unices and Windows, and does provide a very clean abstraction of the thing we generally know as poll().
But this is a C library, isn't it ?
Although I agree that performance very important, it is my experience that the percentage of time spent in the scheduling parts of an I/O-bound application is rather miniscule. It doesn't really matter whether you maintain your poll() array with zero copies all the time, or whether you use epoll(), /dev/poll, kqueue(), or select(). These things may make a difference in benchmarks, but not in real-life applications.
My understanding is that many boost users are looking for the best performance and are building server apps where it could matter. I am looking for best raw performance without having to use C
What I could definitely do is to get the source code I have right now checked into the Boost sandbox under an appropriate license, then we'll see where it goes from there. ;-)
Shouldn't the scheduler be renamed "reactor" ? Also, I have the impression that many people would develop web apps in C++ if there was a basic set of libraries that make the job feasible, so in that sense the reactor pattern and your FastCGI C++ make a nice couple. I think there are three levels of demand for a boost networking library 1) reactor --> for users wanting to develop network apps 2) fastcgi --> for users wanting to develop web apps interfacing with existing web servers 3) other --> for users wanting to develop very complex network apps where more abstractions are needed (combining reactor, threads, ...) Your library would fit levels 1 and 2 and the other libraries might be more appropiate for 3
On 8/11/05, Jose <jmalv04@gmail.com> wrote:
On 11 Aug 2005 10:38:00 +0200, Peter Simons <simons@cryp.to> wrote:
Jose writes:
I think there are three levels of demand for a boost networking library
1) reactor --> for users wanting to develop network apps
I would add proactor in this level also.
2) fastcgi --> for users wanting to develop web apps interfacing with existing web servers
Is this possible into boost? cgis arent too much tied to the web server? This would lead to too much maintenance overhead to keep it working with the most of them.
3) other --> for users wanting to develop very complex network apps where more abstractions are needed (combining reactor, threads, ...)
Or the proactor could go in here.
Your library would fit levels 1 and 2 and the other libraries might be more appropiate for 3
I think the levels should accompany from lower to higher abstractions inside the library. Like: sockets -> demultiplex -> reactor/proactor, or something like this. And as for fastcgi it could be an "another library" that uses one of the levels of the networking library. -- 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/11/05, Felipe Magno de Almeida <felipe.m.almeida@gmail.com> wrote:
I think there are three levels of demand for a boost networking library
1) reactor --> for users wanting to develop network apps
I would add proactor in this level also.
Proactor should go in the third level to keep this simple and maximize adoption. The reactor pattern with an http example would get library users coding right away The asio library also implements the proactor pattern
2) fastcgi --> for users wanting to develop web apps interfacing with existing web servers
Is this possible into boost? cgis arent too much tied to the web server? This would lead to too much maintenance overhead to keep it working with the most of them.
It may sound odd to mention fastcgi here. Check this for background info http://cryp.to/publications/fastcgi/ The fastcgi interface is quite stable and the actual idea here is that you can use any front end web server that supports the interface. The architecture is quite elegant if you think that the front end support all the common web stuff and you have a custom server that ties nicely with the web server. Again it might sound rare to mention cgi here but I think this would tie nicely with the idea of making boost a powerful library for any type of network apps, web apps being the most common.
3) other --> for users wanting to develop very complex network apps where more abstractions are needed (combining reactor, threads, ...)
Or the proactor could go in here.
Yes. Logging would also be a core part here. The idea is not to reinvent ACE but to have a progressive framework that you can start with at level 1 but move to level 3 for any type of serious networking app. There is a limit here where you probably end up using ACE for really complex stuff.
And as for fastcgi it could be an "another library" that uses one of the levels of the networking library.
In an abstract way I compare fastcgi to regexp. They are de facto standards for doing certain things and as result they are very useful. Again, the fastcgi architecture is elegant but not widely used because it is not in the vendor's best interest.
Jose writes:
Personally, find working with read(), write(), and plain plain file descriptors to be much simpler than using any of those fancy iostream classes.
I'd like to see a pros/cons comparison of both approaches.
I don't think it makes much of a difference which API you use. When writing asynchronous I/O handlers, the basic structure is almost always the same: 1. fd becomes readable, 2. read() as much as possible, 3. process the available input, 4. write() the results you've computed, 5. return and wait until (1). So (usually) there are exactly two places where you do I/O -- as opposed to synchronous I/O where you read some value, process it, read some other value, process that, etc. On those two occasions where I actually _do_ I/O, it doesn't matter whether I type "write(fd, buf, len)" or "ostream.write(buf, len)". In fact, most of the application code I write for use with asynchronous I/O doesn't do any I/O _at all_. The handlers operate on memory buffers only, so that the underlying I/O code can be generic. The FastCGI library is a nice example for that; it is completely independent of the underlying I/O driver. You can use it synchronously or asynchronously, it doesn't matter.
But this is a C library, isn't it ?
Yes, libevent isn't an ideal I/O driver for C++ programs. I just think it demonstrates nicely that with nothing more than the functions struct event; void event_set(struct event *ev, int fd, short event, void (*fn)(int, short, void *), void *arg); int event_add(struct event *ev, struct timeval *tv); int event_del(struct event *ev); int event_dispatch(); ..., you can write full-blown asynchronous I/O servers, and they'll run on both Unix and Windows. Plus, there is a very obvious translation of that API into C++. Now, given how _simple_ that programmer interface is, I can't help but wonder why other libraries need dozens of classes, templates, and helper functions to do the same job.
Shouldn't the scheduler be renamed "reactor" ?
I don't know. ;-) To me, when people talk about schedulers, demuxers, reactors, proactors, and whatnot else, it's all the same thing: it's an event loop that jumps into a bunch of callbacks. I don't feel strongly about the name to use for that. The term "scheduler' seemed to describe nicely what my class does, that's the only reason I picked it. Peter
I don't think it makes much of a difference which API you use. When writing asynchronous I/O handlers, the basic structure is almost always the same:
1. fd becomes readable, 2. read() as much as possible, 3. process the available input, 4. write() the results you've computed, 5. return and wait until (1).
From my understanding, you're describing "reactive" event handling systems. In reactive systems, you get notified when I/O can be performed, then you go do it . In proactive, you initiate the operation (either read or write), and the OS notifies you when the operation has completed. I'm clarifying because when I see "async network io" I usually think of proactive models, rather than reactive models (I think the Linux asio library is a proactive model ...).
In fact, most of the application code I write for use with asynchronous I/O doesn't do any I/O _at all_. The handlers operate on memory buffers only ...
This is the level of abstraction that I hope makes it into a Boost networking (or general I/O multiplexing) library - the application code should be able to register a callback (e.g. using Boost function) that the multiplexor calls when an I/O operation completes.
I don't know. ;-) To me, when people talk about schedulers, demuxers, reactors, proactors, and whatnot else, it's all the same thing: it's an event loop that jumps into a bunch of callbacks.
That may be simplifying it a little bit too much - reactive and proactive models do differ significantly in a number of details (including interface semantics), although at the application callback level it might be best to abstract or hide those kind of details.
I don't feel strongly about the name to use for that. The term "scheduler' seemed to describe nicely what my class does, that's the only reason I picked it.
I've been using forms of the word "multiplexor" in work-related projects for a while, and I've seen it used here in the Boost list. I like it better than scheduler, which I've seen in many other contexts outside of what we're discussing. For those using ACE (or are familiar with the communication pattern terminology), the terms Reactor and Proactor immediately communicate a lot of information ... Cliff
On 8/12/05, Cliff Green <cliffg@codewrangler.net> wrote:
I'm clarifying because when I see "async network io" I usually think of proactive models, rather than reactive models (I think the Linux asio library is a proactive model ...).
Just to clarify one point: asio is portable. It runs on Windows (using I/O completion ports), Linux (via epoll or select), Solaris and *should* work on any other UNIX-like platform that supports select(2). I had to make a couple of very simple changes to get it to compile on OS/X (the gethostby*_r functions don't seem to be available on this platform). -- Caleb Epstein caleb dot epstein at gmail dot com
Hi Caleb, --- Caleb Epstein <caleb.epstein@gmail.com> wrote:
Just to clarify one point: asio is portable. It runs on Windows (using I/O completion ports), Linux (via epoll or select), Solaris and *should* work on any other UNIX-like platform that supports select(2). I had to make a couple of very simple changes to get it to compile on OS/X (the gethostby*_r functions don't seem to be available on this platform).
In fact I have a patch for OS/X which should be in asio 0.3.3. However I believe the functions it uses are not guaranteed to be thread-safe until 10.4, so you would only be able to use asio in a single-threaded program for earlier OS/X releases. Basically the approach I have been taking has been to make asio portable first (via select) and then to optimise for each platform. For example, it theoretically supports implementations that use /dev/poll on Solaris and kqueues on on *bsd (including OS/X AFAIK). Cheers, Chris
On 8/12/05, Christopher Kohlhoff <chris@kohlhoff.com> wrote:
Hi Caleb,
--- Caleb Epstein <caleb.epstein@gmail.com> wrote:
Just to clarify one point: asio is portable. It runs on Windows (using I/O completion ports), Linux (via epoll or select), Solaris and *should* work on any other UNIX-like platform that supports select(2). I had to make a couple of very simple changes to get it to compile on OS/X (the gethostby*_r functions don't seem to be available on this platform).
In fact I have a patch for OS/X which should be in asio 0.3.3. However I believe the functions it uses are not guaranteed to be thread-safe until 10.4, so you would only be able to use asio in a single-threaded program for earlier OS/X releases.
Or you could implement a custom thread-safe implementation of the asio resolvers that holds a mutex while resolving names on OS/X < 10.4. Its a pain, and not 100% bulletproof (what if someone links with some other library that is using gethostby* in another thread?), but its just about the best you can do given a thread-unaware runtime. Another approach, which I've used from time to time, is to provide your own version of the unsafe C runtime functions that hold a mutex while calling the unsafe C library routine and copy the result into thread-specific storage and return that pointer. As long as your implementation gets linked in before the libc version, you've solved the problem in all cases.
Basically the approach I have been taking has been to make asio portable first (via select) and then to optimise for each platform. For example, it theoretically supports implementations that use /dev/poll on Solaris and kqueues on on *bsd (including OS/X AFAIK).
Its a very nice library. I commend you on the design and implementation. Personally, I think this should be proposed as a Boost. Networking library more or less as-is. -- Caleb Epstein caleb dot epstein at gmail dot com
Caleb Epstein wrote:
Its a very nice library. I commend you on the design and implementation. Personally, I think this should be proposed as a Boost.Networking library more or less as-is.
I second that opinion. Asio has really impressed me - in fact I'm abandoning ACE in favor of it.
Peter Petrov wrote:
Caleb Epstein wrote:
Its a very nice library. I commend you on the design and implementation. Personally, I think this should be proposed as a Boost.Networking library more or less as-is.
I second that opinion. Asio has really impressed me - in fact I'm abandoning ACE in favor of it.
I also approve, and I'm about to start using it to replace my hand written networking code. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - Grafik/jabber.org
--- Rene Rivera <grafik.list@redshift-software.com> wrote:
Peter Petrov wrote:
Caleb Epstein wrote:
Its a very nice library. I commend you on the design and implementation. Personally, I think this should be proposed as a Boost.Networking library more or less as-is.
I second that opinion. Asio has really impressed me - in fact I'm abandoning ACE in favor of it.
I also approve, and I'm about to start using it to replace my hand written networking code.
Wow! Given the encouraging response both on and off list, I guess I'd like to kick things off in turning asio into a serious proposal for Boost. I'll post a message in a day or two outlining some of the areas where I believe it needs refinement and where it could benefit from others' expertise. Cheers, Chris
Christopher Kohlhoff wrote:
Wow! Given the encouraging response both on and off list, I guess I'd like to kick things off in turning asio into a serious proposal for Boost. I'll post a message in a day or two outlining some of the areas where I believe it needs refinement and where it could benefit from others' expertise.
Great! Here are some refinement/enhancement ideas: 1. Asynchronous versions of basic_host_resolver::get_host_by_name() and basic_host_resolver::get_host_by_address(). 2. IPv6 support. 3. SSL/TLS support via OpenSSL would be great. Datagram-level security using DTLS would be even greater, although not so important (OpenSSL 0.9.8 has DTLS support). Contrary to previous posters, I don't think you have to bother with HTTP support or examples - it's outside of the scope of this library, and should be implemented separately (on top of it) by another library.
Cheers, Chris
Peter
I'm pointing at your annoucement post last year http://lists.boost.org/Archives/boost/2004/09/71923.php
The inspiration for asio was the work of Alex Libman in developing a "portable Proactor framework" for ACE (see http://www.terabit.com.au). This is a Proactor that can use select or a similar synchronous event demultiplexer if no more appropriate OS mechanism is available.
and the proactor white papers which I found very useful in understanding how all fits together http://www.terabit.com.au/articles.php Given the rationale in the papers I understand that your library provides a multiplatform async network io solution (emulating async behaviour in Linux via select-like mechanisms) but that it will be able to include true async network aio_ calls when these are available. My questions are: 1) Is this a solution that will incorporate async disk io in the future by wrapping the POSIX aio_ interface or just network focused ? (i.e. boost::net vs boost::aio) 2) Shouldn't the host resolver interface wrap the system getaddrinfo calls so that it is IP6 ready as well ( should IP6 be a priority or just making the sure the design is able to accommodate it easily when necessary ?) In Linux, shouldn't the host resolver wrap the native async getaddrinfo_a for best performance ? 3) How can the library tap into the ideas/experience of the other library users ? E.g. the nanostream library has some work that might be complementary. 4) HTTP: I asked for this just for the examples understanding that a fully fleshed out library would be separate and probably tie more with a web applications library, a wide field in itself. The nanostreamer class also has initial work here that would be nice if it could somewhat be coordinated Finally, it would be nice if in addition to your TODO list you can provide some document that explains the current design decisions (e.g. how you use threads,,..) beyond what is in the proactor pattern Thanks Jose On 8/15/05, Christopher Kohlhoff <chris@kohlhoff.com> wrote:
--- Rene Rivera <grafik.list@redshift-software.com> wrote:
Peter Petrov wrote:
Caleb Epstein wrote:
Its a very nice library. I commend you on the design and implementation. Personally, I think this should be proposed as a Boost.Networking library more or less as-is.
I second that opinion. Asio has really impressed me - in fact I'm abandoning ACE in favor of it.
I also approve, and I'm about to start using it to replace my hand written networking code.
Wow! Given the encouraging response both on and off list, I guess I'd like to kick things off in turning asio into a serious proposal for Boost. I'll post a message in a day or two outlining some of the areas where I believe it needs refinement and where it could benefit from others' expertise.
Cheers, Chris _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi Jose, --- Jose <jmalv04@gmail.com> wrote:
Given the rationale in the papers I understand that your library provides a multiplatform async network io solution (emulating async behaviour in Linux via select-like mechanisms) but that it will be able to include true async network aio_ calls when these are available.
Yep, that's it pretty much exactly.
1) Is this a solution that will incorporate async disk io in the future by wrapping the POSIX aio_ interface or just network focused ? (i.e. boost::net vs boost::aio)
That's why I called the library "asio" (== ASynchronous I/O) rather than something something based on network/socket ;) Seriously, sockets were implemented first because that's what I needed first, but I think any OS resource that lends itself to asynchronous I/O is worth considering.
2) Shouldn't the host resolver interface wrap the system getaddrinfo calls so that it is IP6 ready as well ( should IP6 be a priority or just making the sure the design is able to accommodate it easily when necessary ?)
Yes, although in the current design this would be asio::ipv6::host_resolver. I think IPv6 is probably important, but I personally have no experience with it.
In Linux, shouldn't the host resolver wrap the native async getaddrinfo_a for best performance ?
I wasn't aware of such a function, and will investigate it.
3) How can the library tap into the ideas/experience of the other library users ? E.g. the nanostream library has some work that might be complementary. [... HTTP and nanostream ...]
Yep, I agree, it would be worth revisiting the other libraries that are out there to see if there are ideas to help refine the design.
Finally, it would be nice if in addition to your TODO list you can provide some document that explains the current design decisions (e.g. how you use threads,,..) beyond what is in the proactor pattern
Over the next few weeks I hope to write some short web pages about each of the major design decisions taken (and some that still need to be taken). Cheers, Chris
On 8/16/05, Christopher Kohlhoff <chris@kohlhoff.com> wrote:
--- Jose <jmalv04@gmail.com> wrote:
In Linux, shouldn't the host resolver wrap the native async getaddrinfo_a for best performance ?
I wasn't aware of such a function, and will investigate it.
On Tue, 16 Aug 2005 00:15:54 +1000 (EST) Christopher Kohlhoff <chris@kohlhoff.com> wrote:
Wow! Given the encouraging response both on and off list, I guess I'd like to kick things off in turning asio into a serious proposal for Boost. I'll post a message in a day or two outlining some of the areas where I believe it needs refinement and where it could benefit from others' expertise.
I know you want a header only library, but others have voiced the need to not pollute the namespace with all the stuff from various network library header files and such. This almost requires a library implemented behind the interface. Along that line, compiles are very slow, probably due to the all-header implementation. I looked at asio a while ago, and remember having some other issues, but do not really recall them at this moment.
Hi Jody, --- Jody Hagins <jody-boost-011304@atdesk.com> wrote:
I know you want a header only library, but others have voiced the need to not pollute the namespace with all the stuff from various network library header files and such. This almost requires a library implemented behind the interface.
Given that such a decision should not affect the library's interface, I think it's an implementation approach that is worth discussing (although perhaps after the external interface is refined ;). However, due to the heavy use of templates only a small amount of it would be able to go in a library (e.g. OS wrapper facades).
Along that line, compiles are very slow, probably due to the all-header implementation.
I find it slowest with g++, but quite fast with MSVC say, even without precompiled headers. I put the slow compile speed down to the use of templates more than the headers themselves because g++'s precompiled header support only sped up the compile by about 30%. Cheers, Chris
participants (4)
-
Beman Dawes -
Caleb Epstein -
Christopher Kohlhoff -
Cliff Green -
David Abrahams -
Felipe Magno de Almeida -
Jeff Flinn -
Jody Hagins -
Jose -
Michel André -
Peter Petrov -
Peter Simons -
Rene Rivera