mailing list archives
Re: Options to replace select in Nsock
From: Brandon Enright <bmenrigh () ucsd edu>
Date: Sun, 21 Jun 2009 01:34:11 +0000
On Sun, 21 Jun 2009 01:19:28 +0000
doug () hcsw org wrote:
A poll implementation with a select fallback is probably fine.
I agree than in the short(ish) term moving to poll() is probably the
best solution. Thinks like kqueue and epoll do sound nice though.
Maybe a SoC project or something?
Is this really a common issue? The ways I use nmap usually only opens
a few hundred descriptors at most in which case a stateful API
provides little benefit. But of course I'm not doing things like NSE
scanning /16s and whatnot like Brandon is. :)
Really this isn't even a common problem for me. I've known about some
sort of Nsock bug on huge scans for a while now and my strategy has
just been to not do those scans. Until NSE came around it was *really*
hard to hit the limit. Anybody doing -sV with a parallelism in the
10,000+ range was just asking for trouble.
It is becoming more reasonable to do things with NSE like running a
single script across millions of hosts. When that script can hold onto
a socket for a while (think long UDP timeout for example) it is
moderately likely to run into a problem.
So in short, this isn't a new, huge, or showstopping problem. It's
something we should fix but not at the cost of stability or
portability. We can work on the problem at a leisurely pace. I can
even see migrating to poll() similar to how Postgres did it and then
having a SoC project to work on CompletionPorts/kqueue/epoll and
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org