Retransmitting does not change the set of incomplete hosts, so there's
no need to use a map to store the current position in the outstanding
probes queue. Using a vector is much faster. Additionally, improper use
of std::map::find() and std::map::operator[] meant that the O(logN)
lookup was happening 4 times for a single host for each iteration
through the loop. Complexity for N targets is now O(N), not O(N logN)
UltraProbe's tryno and pingseq attributes were mutually exclusive,
encoded in the same places in packets, and did not need more than 7 bits
to store. This change combines them into a bitfield. This simplifies
some logic, since they do not need to be distinguished from each other.
Additionally, in cases where the tryno is encoded in the source port
number, no further checks or decoding need to happen beyond comparing
the destination port of the response to the source port of the probe.
When tying UDP payloads to tryno, we were exceeding the maxtries in
order to send all available payloads, leading to assertion failures.
Currently there are not more than 4 payloads for any given port; most
have none, many have 1, very few have more. So we will send them all at
the same time with the same source port/tryno.
The actual number only matters for certain debug output, so replaced
this frequently-called function with one that short-circuits to return a
boolean. Mostly only matters for host discovery scans, since all others
were only a few instructions already.
Two essential changes:
1. (ab)Use the ratelimit detection feature to hold off sending retransmissions,
preferring to send new ARP probes. Late responses will still be recorded, but no
longer counted as drops. This also gives each target the longest amount of time
to respond.
2. Send timing pings much more frequently. Since we're not sending any
retransmissions until timeout + ratelimit, we wouldn't otherwise have any data
on drops in order to speed up or slow down.
Results are faster ARP scans with fewer missed targets. See #92.
This feature allows programs consuming XML output to know when a target
has been found to be "up" before all scan phases are completed. This is
helpful for allocating storage, communicating scan progress, or
estimating total scan duration. Closes#1858.
We probably want a more explicit handling of the case where we get an
ARP response to a request that we did not send (system's own, or another
Nmap scan running at the same time). In any case, this ought to solve
the crashes reported as #1797 and #1764.
