Re: get_max_open_descriptors() is more generous than Nsock.

["Luis MartinGarcia." <luis.mgarc () gmail com>]

On 12/19/2011 02:30 PM, Henri Doreau wrote:
> 2011/12/19 Luis MartinGarcia. <luis.mgarc () gmail com>:
> > I should know the answer to this but, what's the current status of the
> > nsock-engines branch? Has it been merged into trunk? If it has, how do I
> > determine if the selected engine is select()-based or uses something
> > better? I'd like to find a way to use more than 1024 descriptors when
> > possible, not just use 1024 by default.
> The branch is still on nmap-exp and I keep on maintaining it (though I
> should check whether everything is fine after the recent changes on
> the SVN infrastructure). There are just a couple (AIX-related)
> revisions that haven't been merged yet from nsock (trunk), as I can't
> test them. So currently you can assume that nsock uses select(2).
>
> nsock-engines offers no way to get the engine identifier or
> characteristics, as I absolutely wanted to preserve the external API,
> but adding getters would be easy, just need to know what is desired.

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,

Luis.








_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/