c-ares / c-ares / #175

92%

push

travis-ci

Replace hosts parser, add caching capabilities (#591)

HOSTS FILE PROCESSING OVERVIEW
==============================
The hosts file on the system contains static entries to be processed locally
rather than querying the nameserver.  Each row is an IP address followed by
a list of space delimited hostnames that match the ip address.  This is used
for both forward and reverse lookups.

We are caching the entire parsed hosts file for performance reasons.  Some
files may be quite sizable and as per Issue #458 can approach 1/2MB in size,
and the parse overhead on a rapid succession of queries can be quite large.
The entries are stored in forwards and backwards hashtables so we can get
O(1) performance on lookup.  The file is cached until the file modification
timestamp changes (or 60s if there is no implemented stat() capability).

The hosts file processing is quite unique. It has to merge all related hosts
and ips into a single entry due to file formatting requirements.  For
instance take the below:
```
127.0.0.1    localhost.localdomain localhost
::1          localhost.localdomain localhost
192.168.1.1  host.example.com host
192.168.1.5  host.example.com host
2620:1234::1 host.example.com host6.example.com host6 host
```
This will yield 2 entries.
1) ips: `127.0.0.1,::1`
    hosts: `localhost.localdomain,localhost`
2) ips: `192.168.1.1,192.168.1.5,2620:1234::1`
    hosts: `host.example.com,host,host6.example.com,host6`

It could be argued that if searching for `192.168.1.1` that the `host6`
hostnames should not be returned, but this implementation will return them
since they are related (both ips have the fqdn of host.example.com).  It is
unlikely this will matter in the real world.


Fix By: Brad House (@bradh352)

543 of 543 new or added lines in 7 files covered. (100.0%)

5756 of 7102 relevant lines covered (81.05%)

2240.0 hits per line