Nmap Development mailing list archives
Re: nmap-poll branch results
From: Florian Vichot <florian.vichot () diateam net>
Date: Wed, 26 Aug 2009 16:01:10 +0200
Hi all, I realise I may be a little late to the conversation, but why not use something like libevent (http://www.monkey.org/~provos/libevent/)? It provides an abstraction layer for select and poll, as well as more advanced options like epoll and kqueue, and event ports on Solaris. It also supports Windows. It's a well maintained, BSD-licensed library, used by Honeyd and Tor. Any reason why not ? Just my 2 euro-cents, Florian J Marlow a écrit :
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
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- nmap-poll branch results J Marlow (Aug 25)
- Re: nmap-poll branch results Florian Vichot (Aug 26)
- Re: nmap-poll branch results David Fifield (Aug 28)
- Re: nmap-poll branch results majek04 (Aug 31)
- Re: nmap-poll branch results David Fifield (Aug 28)
- Re: nmap-poll branch results Florian Vichot (Aug 26)