Change batch_size and ulimit type

[koloiyolo]

Issue

Hi while playing with Your tool i stumbled across this message:

[~] File limit higher than batch size. Can increase speed by increasing batch size '-b 524188'.

But when I ran tool with reccomended parametr I got:

➜  release git:(master) ./rustscan -a www.google.com -b 524188
error: invalid value '524188' for '--batch-size <BATCH_SIZE>': 524188 is not in 0..=65535

For more information, try '--help'.

After further inspection I found out that batch_size is u16 which indeed can hold up to 65535, and that is way lower than some OSes can use.

My OS info

OS	Kernel	ulimit -Hn	CPU
Fedora 42 Workstation	x86_64 Linux 6.15.6-200.fc42.x86_64	524288	i7 7500u

Thought process

• Considering that batch_size variable is directly tied to ulimit variable it made sense for those 2 variables to use the same type. Especially when those values are being compared.
• Considering that ulimit is directly tied to OS and OS architecture it made sense for this type to be usize which is affected by OS architecture.

Also quick thought. Capping the batch_size based on OS ulimit may fix the issue described here.

What does it change

• Let's user assign higher batch_size which may increase tool performance based on user's OS ulimits and may be helpful when scanning multiple addresses.
• Removes no longer needed conversions which may improve performance.
• Doesn't change defaults and current behavior of the tool.

Benchmarks

Using time on precompiled binaries with 'cargo build --release':

• Defaults:

./rustscan --greppable -a www.google.com  2.01s user 3.11s system 22% cpu 22.950 total
./rustscan --greppable -a www.google.com  1.89s user 3.04s system 21% cpu 22.955 total

• batch_size based on OS cap:

./rustscan --greppable -a www.google.com -b 524188  2.14s user 4.98s system 105% cpu 6.757 total
./rustscan --greppable -a www.google.com -b 65535  2.08s user 4.99s system 104% cpu 6.780 total
./rustscan --greppable -a www.google.com -b 65535  2.10s user 5.09s system 103% cpu 6.952 total

As You can see the higher batch size makes initial memory allocation a bit slower but overall program executions are way quicker.

[koloiyolo]

Seems the fail is not related to my changes.
(Edit) Fixed.

[Copilot]

Pull request overview

This PR changes batch_size and ulimit types from fixed-size integers (u16, u64) to platform-dependent usize to support systems with very high file descriptor limits (e.g., 524,288 on Fedora 42). This removes the artificial cap of 65,535 on batch size that prevented users from fully utilizing their system's capabilities.

Key Changes:

• Changed batch_size from u16 to usize across the codebase
• Changed ulimit from u64 to usize for consistency
• Removed unnecessary type conversions and simplifications

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
src/input.rs	Updated batch_size and ulimit field types in Opts and Config structs from u16/u64 to usize
src/main.rs	Updated constants, function signatures, and logic to use usize for batch_size and ulimit; removed now-unnecessary .try_into() conversion
src/scanner/mod.rs	Updated Scanner struct and constructor to accept batch_size as usize instead of u16
tests/timelimits.rs	Modernized string formatting to use inline format arguments
benches/benchmark_portscan.rs	Simplified closure by removing unnecessary wrapper function call

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.