[bind10-dev] msgq and dhcp4

[Tomek Mrugalski]

Hi,

I'm trying to integrate dhcp4 into msgq support. Currently it is a
stand-alone component that just happens to be in bind10 source tree.

Current code creates sockets using standard POSIX calls, not asio. The
reason it was written that was is that we need to do extra DHCP tricks,
like binding sockets to specific interface, joining multicast groups or
eventually receiving/sending data to hosts that do not have address
configured yet. Also, we need to receive/send packets using
recvmsg()/sendmsg().

When I tried to mimic auth or resolver implementation, I got stuck when
calling io_service.run(). I created ModuleCCSession with config and
command handlers and started session. However, when I called
io_service.run(), it blocks, so I can't get into main dhcp loop. It
seems that current traffic handling model is not compatible with msgq. Doh!

During normal dhcp operation 3 types of events may occur:
1. a packet was received over one of many sockets (typically one socket
per interface, but it may vary)
2. a timer expires (e.g. lease expires)
3. a command or new config arrives over msgq

Doing 1 and 2 is easy (select() + calculated timeout). Doing 1-3 is more
complicated.

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

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?

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.

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.

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

If you want to look at the code, it is on trac1651. See
src/bin/dhcp4/main.cc and Dhcpv4Srv::run() in src/bin/dhcp4/dhcp4_srv.cc.

Tomek