On Fri, 23 Dec 2005 09:09:41 +1100 (EST) Christopher Kohlhoff <chris@kohlhoff.com> wrote:
I guess you must be doing some pretty hard-core networking to be concerned about this level of detail. Can you describe a use case that would make such a feature widely useful? Some hard numbers on performance differences would be quite interesting.
Well, you know... I'm looking for the numbers now. I seem to have not only lost the numbers, but the program as well. If I can't find them, then maybe I'll just rewrite the test (as close as I can come to remembering it) on Christmas Day. I should be allowed to do SOMETHING fun on that day...
The standard multicast socket options are implemented in the asio::ipv4::multicast namespace. They are:
There are some other (not so standard, and ipv6) ones, but that should do for now.
From comments, you'll seed that some people prefer header-only and others don't.
Right. Wish there were a way to do both...
It's on my to-do list to investigate a library implementation, but this would be an option, not mandatory. The goal of the library implementation would be to hide away the system headers.
I actually played with a lib implementation using templates. Ended up templatizing on const builtins with values set to the "actual" value from the system header. It's a bit ugly in the implementation, but the usage is quite nice, and a bit more readble. It's is, at least, possibly to do all your template stuff (like socket options and such) in such a manner, without including the system headers directly.
However, a few things need to be considered:
- Much of the library is implemented in templates, so it is likely that only the lowest level OS wrappers would be in a library.
That's OK. The part I don't want included is the OS related junk. That's where my namespace gets polluted, and that's where funky macros come from. All your stuff will be nicely wrapped in the boost::asio namespace.
- I am very concerned that any compilation firewall technique used does not introduce additional memory allocations. I am not yet sure about the best way to achieve this. Some declaration of system types may be required (albeit in a namespace), for example.
Yes, I agree. I still think you can do it without the memory allocations. Basically, you are wrapping the system level stuff (anything that needs non-boost headers) in a library, and providing a think interface (it can even be templates for the most part). There will be a performance cost for the extra function call. While I've been extremely busy, I did try to read the docs. I'm concerned about all the bind() calls. I can live with it the first time, but it looks like I have to rebind after each operation. This can be quite costly. Maybe I'm missing something... I'll try to get some time over the next week to review it a bit more, but this time of year is HECTIC. Kids, XMAS, work deadlines, end of quarter deadlines, end of year deadlines, etc... etc... I even canceled my vacation time (went skiing last weekend with the kids, but other than that, it's all been canceled).