Nmap Development mailing list archives
Re: Looking at the windows 64 sockets allowed bug.
From: James Rogers <jamesmrogers () gmail com>
Date: Sat, 14 Jul 2012 20:08:49 -0400
Yes, it appears to be a slow down unrelated to my patch in the 6.02 branch. Fyodor did not see this slow down, so it might be specific to my own system. I am also researching why windows was intentionally limited to just 5 connections at a time. It may be that there is a problem in previous versions of windows that require the 5 connection limit. On Tue, Jul 10, 2012 at 4:37 AM, Henri Doreau <henri.doreau () gmail com> wrote:
2012/7/9 James Rogers <jamesmrogers () gmail com>:I've done some benchmarking. With the -sT option on 32bit Windows 7 I can scan in 138 seconds compare to 392 seconds in nmap 6.01. This is almost a 3 times speed up. Just to be through, on an unpatched nmap 6.02 the -sT option runs in 362 seconds. An example of this comparison is in -sTtestnmap.jpg that I have attached to this email. I don't have another version of windows with which to test. If someone could try out this patch on their own computer, that would be good. I wouldn't want to add something that breaks ore reduces performance on older versions of the windows build. I tried a normal scan as well, and noticed that the normal scan was taking at least 3 times longer to complete. To make sure this was not caused by the above patch I rechecked out and compiled and in Nmap 6.02 I am seeing 12 second scan times for a single host in the latest Nmap 6.02 compared to 3 to 4 second scan times in Nmap 6.01. An example of this comparison is in NormalNmap.jpg that I have attached to this email. So it looks like scan times have regressed between 6.01 and 6.02 on windows 7 - 32 bit.Hi James, good to see this brought to the surface, thanks for your work. I'm a bit confused though, your FD_SETSIZE patch improves performances, but tests showed an unrelated regression between 6.01 and current SVN trunk, right? If so, this issue should be reported in a different thread on the list. Beside this I have a suggestion concerning the implementation. Would it be doable to have this new FD_SETSIZE set as a single top-level #define in a windows specific header? This would let windows users who're willing to recompile it with a higher FD_SETSIZE value to do it very easily. e.g.: file: mswin32/winclude.h #define NMAP_MAXFD_WIN32 1024 all the other files: #define FD_SETSIZE NMAP_MAXFD_WIN32 (Un)fortunately I don't have any windows system to test all these things... Regards -- Henri
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: Looking at the windows 64 sockets allowed bug. James Rogers (Jul 02)
- Re: Looking at the windows 64 sockets allowed bug. James Rogers (Jul 09)
- Re: Looking at the windows 64 sockets allowed bug. Henri Doreau (Jul 10)
- Re: Looking at the windows 64 sockets allowed bug. James Rogers (Jul 14)
- RE: Looking at the windows 64 sockets allowed bug. Rob Nicholls (Jul 15)
- Re: Looking at the windows 64 sockets allowed bug. David Fifield (Jul 17)
- Re: Looking at the windows 64 sockets allowed bug. James Rogers (Jul 17)
- Re: Looking at the windows 64 sockets allowed bug. Henri Doreau (Jul 10)
- Re: Looking at the windows 64 sockets allowed bug. James Rogers (Jul 09)
- Re: Looking at the windows 64 sockets allowed bug. David Fifield (Jul 17)