Re: [NSE] WHOIS - Now with Queuing and Cached Results.

["Patrick Donnelly" <batrick.donnelly () gmail com>]

On Sat, Jun 14, 2008 at 8:16 PM, jah <jah () zadkiel plus com> wrote:
> On 14/06/2008 02:54, Fyodor wrote:
> > Hi Jah.  Patrick has recently added mutex support to his branch in
> > order to support this sort of feature:
> >
> > http://seclists.org/nmap-dev/2008/q2/0620.html
> >
> > The feature is documented here:
> >
> > http://nmap.org/book/nse-api.html#nse-mutex
> >
> > And is available in his branch in svn://svn.insecure.org/nmap-exp/patrick
> >
> > Maybe you could try implementing whois.nse with this new feature?  It
> > seems much cleaner than the pcap hack (or even than a sleep function
> > would be).
> Hello,
>
> It is a cool feature!  I still haven't finished, but I wanted to
> bring-up something I've noticed.  That is the order in which coroutines
> resume (after the lock on "id" is removed) which, in Patrick's branch,
> isn't the same order as the targets specified on the command line.
> The reason it's notable from the perspective of whois.nse is that for
> several targets in the same range the coroutine that actually finds the
> record and which is pointed to in the Host Script results by the others
> is seemingly random.  Whereas, in the current nmap, it's always the fist
> target in the range that gets the result - making for a cleaner output.
> It might be worth mentioning that the first coroutine locks "id" whilst
> some initialising is done and then all coroutines are allowed to run and
> further locking is done such that concurrent queries can be performed,
> but not at the same whois service.

You shouldn't rely on any order for threads to be run against Targets.
If you would like to impose an order that is very possible by building
an ordered queue yourself for the threads.

Previously the mutex code maintained a stack for waiting threads (so
the last thread to "lock" gets the lock). Now it uses queue for
waiting threads. Again, I don't think this will solve your problem
because it sounds like you want threads run in an order (Targets)
specified via the command line.

> It looks as though this order thing has been worked on since r8060, but
> I can't check whether this has been successful as I'm failing to build
> r8222 with the following errors:
>
> ..\nse_init.cc(17) : fatal error C1083: Cannot open include file:
> 'stdbool.h': No such file or directory
> which was introduced in r8025 and I worked around by wrapping the
> include with #ifndef WIN32 (google said stdbool.h isn't required on
> windows).
> LINK : fatal error LNK1104: cannot open file 'nsock.lib'
>
> If I try building main_test I get:
> ..\output.cc(792) : error C2057: expected constant expression
> ..\output.cc(792) : error C2466: cannot allocate an array of constant size 0
> ..\output.cc(792) : error C2133: 'c_output' : unknown size

These build errors should be fixed.

> This isn't preventing me from continuing as I'm working from r8060, but
> I'd be grateful for a heads-up.
>
> Regards,
>
> jah

Thanks,

-- 
-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