[Dnsmasq-discuss] Patch: Add --ping-timeout option
simon at thekelleys.org.uk
Tue May 22 11:53:32 BST 2012
On 21/05/12 16:56, Aaron Opfer wrote:
> I've been thinking about this. It's clear to me that the only way to
> correctly implement my patch would be to restructure dnsmasq so that it
> waits for a ping response asynchronously. This, of course, would also
> have the added benefit of making the DHCP server capable of servicing
> more than one DHCP request at once while performing the pings, if done
> right. This would be a huge undertaking though, from the looks of it,
> as we'd have to pull apart several functions to do it, shove those into
> select calls, and so on.
The main problem is that there's significant amounts of state that have
to be preserved between receiving a DHCP request and sending the
associated reply. Having many request in flight impacts on dnsmasq's
small memory footprint.
The current scheme works well in most cases: almost all dnsmasq
installations will only ever see one DHCP request at a time, and there's
code to temporarily abandon doing pings if enough simultaneous requests
occur, giving priority to getting answers out over doing ping checks.
For the installations where that doesn't work, namely large DHCP loads
from netbooting many machines simultaneously. --no-ping is all that's
> I don't know if I'm willing to do all that just for my one-off request.
> My patched dnsmasq works for the most part, but obviously not down to
> millisecond precision like I initially believed. Maybe the patch would
> still be salvagable if we used clock_gettime() on Linux (and fallback
> on dnsmasq_time*1000 for other platforms) for calculating the time
> Alternatively, we could make the --ping-timeout option in units of
> 250ms of time, and then just make dnsmasq loop that many times around.
> So instead of:
>> start = time();
>> while (time() - start < PING_WAIT)
> We'd have something like:
>> i = ping_timeout;
>> while (i--)
That would be possible, but I'm still not clear what you use-case is
that needs this.
> And of course, another alternative is to do nothing at all. :-)
That's quite often a good decision, but many people have come up with
new use-cases and got changes in to support them.
More information about the Dnsmasq-discuss