Re: Nsock port scanning

[Henri Doreau <henri.doreau () gmail com>]

2014-05-20 20:23 GMT+02:00 Daniel Miller <bonsaiviking () gmail com>:
> On Tue, May 20, 2014 at 11:33 AM, Jacek Wielemborek <d33tah () gmail com>wrote:
>
> > This would be
> > much easier to develop and would definitely be hackable more
> > easily, but I am worried about the performance. Since standard
> > Lua has no JIT, I believe that the VM would impose quite a lot of
> > overhead which would slow down massive port scans. I'd like to
> > stress though that I hadn't tested the performance of this
> > approach yet and it might turn out to be good enough. Other than
> > that, I absolutely love this idea, especially that the diff for
> > Henri's prototype changes only 400 lines of code.
>
> Jacek,
>
> I wouldn't worry very much about performance, since we are writing a
> network scanner. Jeff Atwood just wrote a great article about the relative
> latencies of computing vs networks, scaled to 1 CPU cyle = 1 second [1]. A
> quick check from a server with 10Gb Ethernet shows network latencies of
> just under 1 ms, which would be about 1 month of scaled time.
> Comparatively, a full context switch of a large process would probably [2]
> be up to 0.1 ms, about 3 days. And context switching would certainly be the
> largest performance loss other than network speed, since it involves large
> amounts of main memory access and kernel processing that's outside our
> hands.
>
> The things I think you should be considering most here are:
>
> 1. Correctness
> 2. Simplicity of implementation
> 3. Ease of maintenance
> 4. Isomorphism with other Nsock areas, so new features apply universally
> 5. Ease of extension (e.g. adding new scan types)
>
> To sum up, "Premature optimization is the root of all evil." -- Donald Knuth
>
> Dan
>
> [1] http://blog.codinghorror.com/the-infinite-space-between-words/
> [2]
> http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html

I totally agree with Dan. Thanks for phrasing it first! :)

Both solutions sound challenging and promising. The NSE approach is
more "experimental" but it would offer features that a rewrite of
ultra_scan wouldn't, like abusing applications to scan ports,
typically.

I don't think that converting ultra_scan little by little the way you
described makes sense. There would be two concurrent event loops doing
the same job. Nevertheless it is already implemented on an
asynchronous event loop so I guess that converting it to nsock
wouldn't require any major architecture changes.

Regards

-- 
Henri
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/