[bind10-dev] msgq and dhcp4

[JINMEI Tatuya / 神明達哉]

At Fri, 11 May 2012 18:36:51 +0200,
Tomek Mrugalski <tomasz at isc.org> wrote:

> I have couple of questions regarding that matter:
> 1. Is it possible to use recvmsg/sendmsg call with asio? How to do that?

For send, I believe you can do whatever for synchronous send
operations, although it would be considered a dirty, not-so-portable
hack: You can simply get the underlying file descriptor by native()
and use it with sendmsg().

For the receiving side, it would depend on what you want (asio already
internally uses recvmsg() for UNIX like systems), but you probably
want to use some ancillary data, and, if so, I'm afraid we cannot do
it with the ASIO interfaces.

> 2. How to organize data reception? Ideally, I would like to have
> something that waits until first packet arrives or timer is expired
> (basically a select() equivalent) or process_one_event() and would call
> it in a loop until shutdown conditions are detected. Is there such a
> thing in asio?

ASIO has timer interfaces, so at least conceptually you should be able
to do that.

> 3. Concurrency model. Taking into consideration current state of
> affairs, I think there are at least 2 possible ways forward:
> a) asio way. We will create sockets in our own special dhcp way and then
> use basic_datagram_socket::assign() to create asio wrappers around them.
> Then we will call io_service.run() (or run_one() in a loop). The problem
> I have with that approach is that I'm not sure how to use recvmsg to get
> details about the sender. I will keep looking at asio documentation and
> hopefully will find it out.
> 
> b) mixed way. We could fork()/pthread_create() and have separate
> process/thread for msgq handling and the main process for dhcp
> operations. This approach would be much easier to implement now, but in
> the long run would require more work as data incoming via msgq be more
> complicated.

[...]

> Unless I hear other recommendations, I will try approach a).

It depends on what exactly you want to do with recvmsg() and how
crucial that specific way is (i.e., whether the goal can be achieved
by some other way).  But if you really need to use special APIs with
recvmsg() with no feasible alternative, I'm afraid option a doesn't
work unless we make internal extension to ASIO.

Option b probably has other variations.  I guess you could use the
msgq interface in a (semi) synchronous mode, getting the underlying
file descriptor and managing it in a separate event handler loop
(using a native select() or whatever).  When you detect incoming data
on the FD, you'll call the msgq interface with synchronous mode.

Frankly, however, I'm not excited with either approach.  Ideally we
should have a single unified I/O framework for all services.  In that
sense, customizing ASIO ourselves might not be that option.  We could
at least ask the ASIO developers whether they are interested in
incorporating the added feature.

> Stephen mentioned that Jinmei raised doubts about asio efficiency. Are
> there any recommendations against it? DHCP is expected to handle around
> 1000 queries/sec, so if asio is good enough for DNS (two orders higher
> traffic), I suppose it will be good enough for DHCP.

I believe the ASIO overhead for the level of thousands datagrams/sec
is marginal.

---
JINMEI, Tatuya