Boost logo

Boost :

From: Stefan Arentz (stefan.arentz_at_[hidden])
Date: 2005-08-19 02:17:20


(Sorry for quoting wrong, but I just subscribed and did not get
Christopher's original message)

Christopher Kohlhoff <chris_at_[hidden]> 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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk