nmap-poll branch results

[J Marlow <joshmarlow () gmail com>]

Hi all,

I've been experimenting with the feasibility of converting nsock to use poll
instead of select.  For a discussion of why this may be desirable, see:
http://seclists.org/nmap-dev/2009/q2/0730.html

The branch I've been working in is nmap-exp/josh/nmap-poll

I wrote a pair of test programs to try to benchmark nsock's behavior; they
are located in nmap-private-dev/nsock-test.  The benchmark program works by
spawning a server which listens to connections.  The client then (using
nsock) connects to the server and receives data.  I've been running this
benchmark with the select-version of nsock that nmap-poll branched from
(revision 14790) and the poll-based version.   I ran the benchmark to
transfer 100,000 K from server to client.

The changes I made to nsock involve linearly traversing the array that is
passed to poll (equivalent to the fd sets in select) on several occasions.
The runtime of nsock_loop in my poll implementation (as shown by gprof)
increases considerably.  However, overall execution of the benchmark program
(as recorded by time on my Linux machine) takes 36.4 seconds real time for
the select implementation and 37.7 seconds real time for the poll
implementation, which doesn't seem to be too much of a difference.  David
points out, however, that this program may be largely IO bound, and so time
doesn't really reflect the increase in nsock_loop's execution time (which is
largely CPU bound looping).  More extensive testing of nmap using nsock-poll
may be desirable so that we can see how nsock behaves in its natural
environment.  This may be a better indicator of how practical the poll
implementation really is.

Other thoughts: perhaps replacing the linear array traversal with a
different data structure (perhaps some sort of binary search) could improve
nsock_loop's performance.  Also, the current nsock-poll implementation tries
to move to poll while changing the rest of the nsock library as little as
possible.  More extensive changes to nsock with poll in mind may yield more
efficient code.

These ideas should probably be explored before any decisions are made
concerning switching to poll in the nmap trunk.

Any questions/thoughts/suggestions?

Cheers,
Josh

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