
(Sorry for quoting wrong, but I just subscribed and did not get Christopher's original message) Christopher Kohlhoff <chris@kohlhoff.com> wrote:
As discussed in the "surveying async network io libraries" thread, I'd like to turn asio (asio.sourceforge.net) into a proposal for a boost networking library. As promised, here is a list of areas where asio could use some refinement.
I'd appreciate input on:
- What people think of the relative importance of the items. For example, what would be required for an initial implementation vs what could or should be left until a later revision.
- Whether the proposed changes are of any value.
- Any other things that should be on the list.
What's Missing ==============
* Asynchronous DNS operations. I think it would be reasonable to say that any operation that can block should have an asynchronous equivalent. Should these operations be cancellable (not necessarily portably implementable anyway)?
Maybe I'm wrong, but I thought most resolvers included with the operating systems are not thread safe and synchronous. Maybe only OS X has it's own async implementation. There are of course third party libraries to do this. What is the Boost policy of linking with foreign libraries? If everything is supposed to happen under the boost umbrella, under the boost source tree then maybe it is an idea to write our own async resolver? Could be a fun spare time project (for me :-).
* IPv6 support. I have no experience with IPv6, so it would be great if someone with experience could help out with the design here.
It is mostly about abstracting addresses and endpoints. Something asio already has right?
* Asynchronous socket close. In certain circumstances closing a socket can block, so it would be reasonable to expect an asynchronous close operation.
* Scatter-gather operations (sendv and recvv).
For efficiency.
* The BSD socket functions sendmsg/recvmsg (which I believe are necessary to support protocols such as SCTP).
* SSL/TLS and DTLS support. This would require an external library, and how does that fit in with boost?
* Other protocols (PF_UNIX, ...)?
Yeah it would be really nice to be able to also hook PF_UNIX sockets in the demuxer. That would be great for local ipc.
* Some type of integration (or support for) a higher-level iostreams-based socket library.
* More examples.
I sort of have a http server example ready. Needs a little bit more love though, then i'll release it or send it to you to see if you want to include it in the distribution. S.