How did I review: browsed through the documentation. The most obviously missing thing is the ready-made support for LOCAL (also called UNIX domain) sockets, or named pipes on Win32. These are very useful and popular IPC mechanisms.
Agreed.
I don't know whether Win32 supports LOCAL domain sockets,
I don't believe it does.
and using Win32 style named pipes won't be portable (as UNIX named pipes are not bidirectional).
This is not a request for implementation, but it would be nice if the author commented whether it is possible to support the following local IPC mechanisms within the library (with possible loss of functionality):
I believe all 4 are possible, with varying degrees of work.
1. anonymous UNIX pipes (pipe(2) system call)
This would require a new abstraction similar to the existing basic_socket_stream (a basic_pipe if you will). Since pipes can be used with select (or epoll or kqueue AFAIK) it should be simple enough to implement the asynchronous operations for it.
2. anonymous UNIX sockets (socketpair(2))
Never used this function myself, but this looks pretty simple to implement. For example (error handling omitted for brevity): template <typename Protocol> void make_socket_pair( const Protocol& p, stream_socket& s1, stream_socket& s2) { int d[2]; socketpair(p.family(), p.type(), p.protocol(), d); s1.set_impl(d[0]); s2.set_impl(d[1]); } Then a protocol class, let's call it unix::stream, would have to be defined. This would be similar to ipv4::tcp or ipv4::udp. This also needs to be done for number 4 below. To use this new function: stream_socket s1(demuxer); stream_socket s2(demuxer); make_socket_pair(unix::stream(), s1, s2); // Now use like any other sockets.
3. named UNIX pipes (created by e.g. mkfifo command) and WIn32 pipes.
As with number 1, this would require a new abstraction, e.g. a basic_named_pipe. As long as the descriptor returned by mkfifo can be used with select (or epoll or kqueue) the asynchronous operations can be implemented. For Win32, named pipes support overlapped I/O, so they should be straightforward to integrate into asio. The tricky part with this one is deciding the appropriate level of abstraction for security (the mode passed to mkfifo or the SECURITY_ATTRIBUTES passed to CreateNamedPipe).
4. LOCAL sockets
New classes for AF_UNIX would have to be defined. That is, the equivalent of ipv4::tcp and ipv4::tcp::endpoint, perhaps called unix::stream and unix::stream::endpoint. Once these are available the existing socket classes can be used as-is. For example: stream_socket s(demuxer); s.connect(unix::stream::endpoint(...));
I cannot give any recommendation since I didn't do a proper review. Overall, judging from the examples and the reference documentation, the library seems simple to use and extensible. Another plus is the header-only implementation.
Cheers, Chris