Re: [boost] [asio] Brief Review

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-10 16:37:49

> 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