Re: [RFC] Crazy idea for deferring hosts in progress to a later hostgroup

[David Fifield <david () bamsoftware com>]

On Thu, Mar 26, 2015 at 10:30:25AM -0500, Daniel Miller wrote:
> 4. What determines a "slow host"? Should there be a numeric limit on how many
> can be deferred? On how many deferrals can happen for one host?

Let's think about some limiting cases.

No targets are considered slow. (No targets are deferred.) That's what
we have now. Slow targets block the flow and prevent other targets from
starting.

All targets but the fastest are considered slow. Port scanning ends as
soon as the first target is done, and all other targets are deferred.
(The next hostgroup will add one fresh target to all the deferred ones
to fill out the group.) If all you're doing is port scanning, then this
is pretty much isomorphic to a continuous pipeline: just keep the target
queue full until you run out of targets. If you're also doing -sV for
example, then it's not so good, because then you'll have just one target
at a time doing -sV.

Maybe what you want is this: Say the hostgroup size is 10. As soon as
the first target finishes during port scanning, you push it onto a queue
(the queue will feed into the -sV phase). You "freeze" the other 9
targets, but you don't go on to -sV just yet; you jump right back into
the port scan, adding one new target to replace the one that finished
and unfreezing the other 9. Then when the next target finishes, you push
it on the queue, and add a new target to replace it. Repeat until there
are 10 targets in the queue. Now you freeze the remaining 9 targets, for
real this time, and jump into -sV scanning the 10 targets in the queue.

What happens when the first target finishes in the -sV scan? I don't
know. I guess you could freeze the -sV scan and resume the port scan,
until it produces a new target to fill the -sV group up again. Then it
would be very like a Unix shell pipeline, where one process, reading
from stdin, blocks until the process before it writes something to its
own stdout. Similarly, a writing process that has filled its output
buffer (queue of 10 targets) blocks until its consuming process pulls
data off the buffer.

David Fifield
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/