Nmap Development mailing list archives
Re: [RFC] Username/Password NSE library
From: "Patrick Donnelly" <batrick.donnelly () gmail com>
Date: Wed, 25 Jun 2008 13:31:53 -0600
On Wed, Jun 25, 2008 at 1:07 PM, Thomas Buchanan
It doesn't really return the table with the intent of sharing it with the caller, just so the for loop can iterate over it. The main advantage to this is the memory reaches a steady state; no new closures or tables are made in a call to the library.Patrick, Can you explain a little more about the memory impact of a closure vs. your for-loop table return? I have to admit I know almost nothing about the underlying code, but as an amateur scriptwriter, I find the flexibility of the closure has quite a bit of appeal. Here's a couple of examples where it doesn't feel natural to me to use a for loop: 1. Testing for a specific amount of time. I would envision a while loop that checks against some timer for each iteration, and returns either when the list of usernames/passwords is complete, or if the timer expires.
It sounds like that could easily be done with an "if time_expired then break end" statement.
2. Imagine a service that returns a different error code for "unknown user" vs. "invalid password". We loop through usernames until we get that magical "invalid password" code, then begin testing passwords with that username.
I envision that working like so: for user in unpwdb.usernames() do for pass in unpwdb.passwords() do local ret = try_connect() if ret == "unkown user" then break; elseif ret == "got connection" then end end end
Now, it's quite probable that you could accomplish both of these with a for loop, but it wouldn't be the first approach that I think of. However, if there is a significant performance benefit to the for-loop structure, then maybe we should sacrifice the flexibility of the closure. Another possibility might be to add your code to the library as an alternative access method that is optimized for for-loops.
It is certainly ok to have both functionalities available. There isn't a "significant" performance benefit. I want to emphasize my original intention that I'm offering this because it seems a good solution to the problem of looping over the table. The closure is perfectly acceptable. It just seemed awkward to me and the generic for loop offered (seemingly) what you guys were seeking. Cheers, -- -Patrick Donnelly "One of the lessons of history is that nothing is often a good thing to do and always a clever thing to say." -Will Durant _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://SecLists.Org
Current thread:
- Re: [RFC] Username/Password NSE library, (continued)
- Re: [RFC] Username/Password NSE library Fyodor (Jun 24)
- Re: [RFC] Username/Password NSE library Philip Pickering (Jun 18)
- Re: [RFC] Username/Password NSE library Kris Katterjohn (Jun 24)
- RE: [RFC] Username/Password NSE library Thomas Buchanan (Jun 24)
- Re: [RFC] Username/Password NSE library Patrick Donnelly (Jun 24)
- Re: [RFC] Username/Password NSE library Kris Katterjohn (Jun 24)
- Re: [RFC] Username/Password NSE library Patrick Donnelly (Jun 25)
- Re: [RFC] Username/Password NSE library Kris Katterjohn (Jun 25)
- Re: [RFC] Username/Password NSE library Patrick Donnelly (Jun 25)
- RE: [RFC] Username/Password NSE library Thomas Buchanan (Jun 25)
- Re: [RFC] Username/Password NSE library Patrick Donnelly (Jun 25)
- Re: [RFC] Username/Password NSE library Kris Katterjohn (Jun 25)
- Re: [RFC] Username/Password NSE library Patrick Donnelly (Jun 25)
- Re: [RFC] Username/Password NSE library Kris Katterjohn (Jun 25)
- Re: [RFC] Username/Password NSE library Patrick Donnelly (Jun 25)
- Re: [RFC] Username/Password NSE library Kris Katterjohn (Jun 25)