From 2461746840012d0ecc72227c7958688f9a52dd91 Mon Sep 17 00:00:00 2001 From: david Date: Sun, 1 Jan 2012 20:26:58 +0000 Subject: [PATCH] Allow --min-rate to trump the built-in limit of 50 sends per wait. --- scan_engine.cc | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/scan_engine.cc b/scan_engine.cc index 30fc50a3f..c625eafd8 100644 --- a/scan_engine.cc +++ b/scan_engine.cc @@ -990,16 +990,6 @@ bool GroupScanStats::sendOK(struct timeval *when) { return false; } - /* There are good arguments for limiting the number of probes sent - between waits even when we do get appropriate receive times. For - example, overflowing the pcap receive buffer with responses is no - fun. On one of my Linux boxes, it seems to hold about 113 - responses when I scan localhost. And half of those are the @#$# - sends being received. I think I'll put a limit of 50 sends per - wait */ - if (recentsends >= 50) - return false; - /* Enforce a maximum scanning rate, if necessary. If it's too early to send, return false. If not, mark now as a good time to send and allow the congestion control to override it. */ @@ -1029,6 +1019,16 @@ bool GroupScanStats::sendOK(struct timeval *when) { } } + /* There are good arguments for limiting the number of probes sent + between waits even when we do get appropriate receive times. For + example, overflowing the pcap receive buffer with responses is no + fun. On one of my Linux boxes, it seems to hold about 113 + responses when I scan localhost. And half of those are the @#$# + sends being received. I think I'll put a limit of 50 sends per + wait */ + if (recentsends >= 50) + return false; + /* In case the user specifically asked for no group congestion control */ if (o.nogcc) { if (when)