Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: get_max_open_descriptors() is more generous than Nsock.
From: Henri Doreau <henri.doreau () greenbone net>
Date: Mon, 19 Dec 2011 15:10:49 +0100

2011/12/19 Luis MartinGarcia. <luis.mgarc () gmail com>:
Hi Henri,

How complicated would it be to implement something like
libnetutil::get_max_open_descriptors() in Nsock? (that function is
basically just a wrapper for getrlimit()) Personally, I think it would
be useful to be able to determine the maximum number of descriptors that
Nsock can handle at runtime.

I am not an expert on Nsocks internals but If that is easy to do, then I
think it is a much cleaner approach than providing getters to determine
the underlying engine and then try to guess the max number of
descriptors. What do you think?

Best regards,



rlimit gives limitations for the whole process and nsock has
limitations (or not) per nsock_pool. Callers can of course open
several pools in parallel (though I think it's not the case in nmap
and its companion tools).

A get_max_open_descriptors()-like function in nsock could return
min(<engine limit>, <rlimit>) and let the users deal with multiple
pools if they have some. That would be easy to implement. The fallback
engine (select-based) will be the only one with such a limitation.

I agree that functions directly returning the information would be
much cleaner, that's what I was thinking about.


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

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]