-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 12 Dec 2007 00:19:37 +0100
Diman Todorov <diman.todorov_at_univie.ac.at> wrote:
> ugh, i'll bet the problem is that bruteTelnet.nse never closes the
> ports it opens and the garbage collector never the socket because
> there is always a reference to it.
>
> I think we'll need to reconsider the open port cap and garbage
> collection policy.
>
> cheers,
> Diman
>
Good find. Here's a random thought on socket exhaustion:
Perhaps each instance of a script should be limited to a small number
of concurrent sockets (~4) and no new script should be allowed to start
unless there are at least that many free sockets out of the max
available.
For example: say we have a max of 10 sockets total, a max of 4 per
script, and two scripts, "A" that opens 4 sockets and "B" that
tries to open 5.
When "B" runs, on the opening of the 5th socket it should be killed
with some error output like "NSE Scripts are limited to 4 concurrent
open sockets".
When "A" runs, each time it opens a socket, another 1 of the 10 are
used. If two instances of "A" are run, there could be 8 sockets used.
At this point, neither "A" nor "B" could be run until at least 2 sockets
are freed.
Now, if one instance of "A" closes 2 sockets and there are only 6 used,
another copy of "A" can be run. Even though the copy of "A" with only
2 sockets open will block if it tries to open a 3rd, there isn't a
permanent deadlock because either of the other copies of "A" should be
able to finish and allow A to open up the 3rd (or 4th) socket again.
This scheme would allow a long running socket hungry script to hold
everything else up but it would prevent the looping or deadlocking
problems. It also shouldn't be much of a problem for a reasonably high
max concurrent socket cap.
Brandon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFHXzlMqaGPzAsl94IRAhpSAJwJQzZW2Et2QneQw3mxsEk2neEm/ACffnmN
75a4Y3WR6SURXBq7ak7B4EU=
=YZUX
-----END PGP SIGNATURE-----
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org
Received on Dec 11 2007
Intro
