Re: Options to replace select in Nsock

[Brandon Enright <bmenrigh () ucsd edu>]

On Sun, 21 Jun 2009 01:19:28 +0000
doug () hcsw org wrote:

...snip...
> 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. :)
>
> Doug

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.

Brandon


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

Attachment: signature.asc
Description:

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org