Fyodor <[EMAIL PROTECTED]> writes: > "totally break the architecture"? I would have used the term > "enhance" or "improve" instead :)
In my dialect, "Complexity" is not a synonym of "enhancement"; it often means "more troubles to come". > Is Nmap the only plugin that would benefit from being able to handle > more than one host at a time? Yes, probably. Because nmap was designed as a standalone tool, while Nessus plugins were designed to run inside the Nessus architecture. Honestly, I don't think that "fixing" this architecture will be worth the cost (development & debuging) > First of all, I am not sure where you get the 25M number. I just > tried on OS scan on my Linux box and it showed under 10M in top 10 MB is quite big for a port scanner, no? > But you statement above mentions the memory use as "per host". This > is again because Nessus is starting dozens of Nmap processes in > parallel, which Nmap wasn't designed for. So this is yet another > advantage of passing multiple hosts to Nmap at once. Run one copy of > Nmap against 64 machines and it will use up 10M of virtual memory. Of _private_ virtual memory. Which means memory allocation, copies, etc. In a word, resources. Isn't there a way to use shareable memory for this fingerprint database? (or whatever it is that uses so much RAM) > You don't need to list it as mandatory. You could put "optional but > heavily recommended") as you presently do with OpenSSL on the download > page. OpenSSL is nearly compulsary. If you don't use it, you will have no SSL at all, as we do not support other libraries yey (GnuTLS...) nmap is the best port scanner available, but there are other options. > I never said it would be trivial to change Nessus so it calls > designated plugins with more than one host at a time. Is it useful? Currently, we can run nmap alone nmap -p 1-65535 -I many_hosts -oN result_file ... and then launch Nessus and "import" the result file. > But I find it hard to believe that maintaining an entire copy of the > Nmap source tree within Nessus will be easier. Well, there are 3 options: A) Maintain a private copy of Nmap B) Implement "parallel" plugins in Nessus C) Modify Nmap to use less memory, or at least use shared memory.
