Home page logo

nmap-dev logo Nmap Development 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[0] and then
having a SoC project to work on CompletionPorts/kqueue/epoll and
Solaris's /dev/poll.


[0] http://archives.postgresql.org/pgsql-committers/2007-12/msg00269.php

Attachment: signature.asc

Sent through the nmap-dev mailing list
Archived at http://SecLists.Org

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]