CERBERUS/nmap
1
0
Fork 0
mirror of https://github.com/nmap/nmap.git synced 2026-08-04 14:49:29 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Remove the code that catches up the --max-rate scheduled send time to

Browse source 
the present. This allows the sending rate to temporarily exceed the
maximum to keep from being slowed too much by other delays in the scan
engine. See the discussion at http://seclists.org/nmap-dev/2008/q3/0236.html.
This commit is contained in:
david 2008-08-11 16:26:17 +00:00
parent bbae5a7845
commit 227adcd664
2 changed files with 10 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

10
docs/refguide.xml
View file

@ -2477,12 +2477,12 @@ seconds.</para>
<para><option>--max-rate</option>, like <option>--min-rate</option>, is
a global option affecting an entire scan. It affects only port and host
discovery scans. Unlike <option>--min-rate</option>, which is a
<quote>best-effort</quote> option, <option>--max-rate</option> is a hard
upper bound on the scanning rate.</para>
discovery scans.</para>
<para>Nmap may go slower than the maximum rate if conditions require it.
To keep the sending rate within a specified range, use
<para>The sending rate may temporarily exceed the maximum to make up for
unpredictable delays, but on average the rate will stay at or below the
maximum. Nmap may go slower than the maximum rate if conditions require
it. To keep the sending rate within a specified range, use
<option>--min-rate</option> and <option>--max-rate</option>
together.</para>

11
scan_engine.cc
View file

@ -888,12 +888,11 @@ void GroupScanStats::probeSent() {
TIMEVAL_ADD(send_no_earlier_than, send_no_earlier_than,
(time_t) (1000000.0 / o.max_packet_send_rate));
if (TIMEVAL_SUBTRACT(send_no_earlier_than, USI->now) < 0) {
/* Even after incrementing send_no_earlier_than, it's still in the past.
That means more packets could be sent immediately and make the rate too
high. Catch the time up to the present to prevent that. */
send_no_earlier_than = USI->now;
}
/* Allow send_no_earlier_than to slip into the past. This allows the sending
scheduler to catch up and make up for delays in other parts of the scan
engine. If we were to update send_no_earlier_than to the present the
sending rate could be much less than the maximum requested, even if the
connection is capable of the maximum. */
if (TIMEVAL_SUBTRACT(send_no_later_than, USI->now) > 0) {
/* The next scheduled send is in the future. That means there's slack time