mailing list archives
Re: Google Summer of Code Nmap Ideas Wanted!
From: David Fifield <david () bamsoftware com>
Date: Sun, 13 Mar 2011 15:31:01 -0700
On Sun, Mar 13, 2011 at 10:54:09PM +0100, Henri Doreau wrote:
2011/3/13 Fyodor <fyodor () insecure org>:
Please take a look, and let nmap-dev (or me) know if you have any
other ideas to consider. Or if you have improvements (or
clarification requests or even just typo discoveries) in the items
already on the list, we'd like to hear those too.
There is something I would really appreciate to see investigated
again: the use of modern IO management functions like poll, epoll,
kqueue/kevent... within nsock.
I have read in todo/nmap.txt that someone already attempted to do such
a thing but faced performance issues due to the architecture of nsock.
I don't know the details of the problem. Would it worth reconsidering this?
Josh Marlow was looking into this. The reason why a port to poll wasn't
trivial is that Nsock processes descriptors in the opposite way from
what poll expects. The usual way to use poll is 1) get a list of active
descriptors, and 2) for each descriptor, do something. Nsock does this:
1) get a list of active descriptors, 2) for each Nsock event, check if
the corresponding descriptor is active, and 3) do something for each one
that is. That is, we walk the event list rather than the descriptor
list. Indexing into the array returned by select is O(1), but checking
if a descriptor is in the linked list returned by poll is O(n).
I still think this is worth looking into, it will just require rewriting
parts of the core event loop. I don't expect that it would have much of
a performance impact in typical Nmap/Ncat use (though we should measure
it). A bigger benefit would be transcending the 1024-descriptor limit
imposed on some systems, which can be exceeded in exceptionally large
Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/