3 Commits

Include renames

Author	SHA1	Message	Date
Autumn (Bee)andAutumn Skerritt	937903340a	Avoid formatting discarded scan errors (#950) ... * perf(scanner): defer TCP error diagnostics * bench(scanner): check open-only TCP and UDP paths * fix(scanner): Import HashSet in tests after main merge --------- Co-authored-by: Autumn Skerritt <[email protected]>	2026-10-05 19:17:26 +09:00
Autumn (Bee)	67c08a3310	Speed up port exclusions and avoid redundant port copies (#954) ... * test(scanner): preserve port filtering order and boundaries * perf(scanner): reuse port lists and index large exclusions * perf(scanner): use bitmap for dense exclusions * bench(scanner): document production port preparation speedups * ci(bench): diagnose repeated macOS listener misses * ci(bench): capture socket errors immediately after listener misses * perf(scanner): keep bitmap storage out of repeated async polls * ci(bench): provision macOS TCP memory for repeated scans	2026-10-02 20:14:56 +09:00
Autumn (Bee)andVrtgs	b7119f7f3e	Port to tokio (supersedes #856, closes #944) (#951) ... * refactor(scanner): run the scanner on tokio instead of async-std async-std is discontinued upstream (RUSTSEC-2025-0052). tokio is already in the dependency tree through hickory-resolver, so switching adds no crate and removes 28 from Cargo.lock (async-std, async-io, polling, async-global-executor, blocking, futures-executor, ...). This is a like-for-like port. The scanner keeps its architecture and the library API keeps its signatures: - a single `FuturesUnordered` keeps at most `batch_size` sockets in flight from one future; nothing is spawned per socket; - connect and UDP receive timeouts use `tokio::time::timeout` and report the same `TimedOut` error that async-std's `io::timeout` did; - open TCP sockets are still shut down in both directions before they are closed (through `into_std()`, because tokio only has a write-side shutdown); - `--interval` sleeps with `tokio::time::sleep`. The binary runs the scan on a current-thread runtime that exists only for the scan. Address resolution (blocking DNS lookups and file reads) runs before the runtime is created and scripts run after it is dropped, so neither can stall the scan, and hickory's internal runtime is never nested in ours. Library users now have to poll the scan futures from a tokio runtime with the I/O and time drivers enabled. The crate and `Scanner` docs say so, and the crate example shows how. Builds on the earlier port in #856 by @vrtgs. Co-authored-by: Vrtgs <[email protected]> * perf(scanner): opt the scan out of tokio's cooperative budget The scan polls every in-flight socket from one future through a `FuturesUnordered`. tokio's cooperative scheduling gives that future a budget of 128 units per poll. Once it is spent, every tokio resource returns `Pending` and defers its wake-up, but `FuturesUnordered` still polls all the other ready sockets in that same poll. When thousands of connections finish together (a burst of refusals, or a batch of timeouts firing at once), the scan keeps re-polling sockets only to park them again, roughly 128 at a time. async-std had no budget. `tokio::task::unconstrained` restores that behaviour: one poll handles every ready socket. The future still returns `Pending`, and so lets the runtime poll I/O and timers, as soon as no socket is ready. * perf(scanner): send UDP probes before registering the socket with tokio tokio's socket I/O is readiness based: `UdpSocket::send` and `recv` first wait until the reactor has reported the socket ready and only then make the system call. async-io, which async-std used, made the call first and only waited after `WouldBlock`. With a straight port, every UDP probe therefore made an extra trip through the event loop before its send. Probes to closed ports on the local host also no longer finished in their first poll: there the ICMP "port unreachable" is usually queued before `send` returns, so async-std's first `recv` already saw the refusal. Bind a non-blocking std socket instead, send the probe and try the first receive straight away. The socket is only handed to tokio, and registered with its reactor, when there is really something to wait for. Errors and timeouts are reported exactly as before. * ci: add an opt-in scan benchmark comparing a change with its base The test suite deliberately never opens sockets (see #942), so nothing in CI showed whether a change to the scanner makes RustScan slower, hungrier or wrong. The tokio port (#944) needs exactly that evidence. The "Scan benchmark" workflow runs for pull requests that touch the scanner, its runtime or its dependencies, and on demand. It builds the change and its base in release mode on Linux x64/arm64, macOS and Windows runners. It then runs .github/scan-benchmark/scan_bench.py, which: - opens 315 TCP listeners and 32 UDP responders on 127.0.0.1 inside the runner. Nothing outside the runner is scanned. Ports stay out of the ephemeral range, so a scan can never connect a socket to itself; - scans them with both builds, alternating the build order between runs: full TCP sweeps with batch sizes 500/4500/10000, 8 loopback hosts, one port, a UDP sweep, and on Linux ports that iptables drops (filtered TCP and UDP, and a mixed sweep), so timeouts are measured too; - fails unless every run finds every listener and no build reports ports the base never found, or misses ports the base always found; - reports medians of throughput (from RustScan's own scan timer), wall time, time to the first open port, peak RSS, CPU time, and sampled peak descriptors and threads. The table goes to the job summary, the raw data to an artifact; - fails if the change's median throughput or wall time is more than 15% worse, or its peak RSS more than 25% worse, in any scenario. contributing.md documents the workflow as the place where scanning is measured, next to the rule that tests must not scan. * ci(scan-benchmark): temporarily compare the port's intermediate builds (to be reverted) * Revert "ci(scan-benchmark): temporarily compare the port's intermediate builds (to be reverted)" This reverts commit 30ac107c55. * fix(scanner): let the runtime poll I/O while a batch is started The scan drives every socket from one future on a current-thread runtime, so the runtime only polls for I/O and fires timers between two polls of that future. A poll only ended once no socket was ready, which could take a long time: - starting a whole batch at once: 8,191 sockets took longer than a 500 ms timeout on the Windows runner, so connections that had succeeded during the fill were only seen after their timers fired. The benchmark found no open port at all with `-b 10000 -t 500` there; - UDP probes to closed ports on the local host finish straight away, so a whole sweep ran in one poll, and the replies from open ports waited until the end: the first open UDP port was reported 2.6x later than with async-std. `scan_sockets` now starts and finishes sockets in rounds of at most 128 (`WORK_PER_TURN`, both counted together) and calls `yield_now()` between rounds, which defers its wake-up until the runtime has polled the OS selector without blocking. Each round still keeps up to `batch_size` sockets in flight; the batch now fills over several rounds instead of in one go. The cost is one extra non-blocking `epoll_wait` (or equivalent) per 128 sockets. * fix(scanner): see ICMP errors on UDP sockets that wait in tokio A UDP probe that gets no answer straight away is handed to tokio to wait for the reply. On Linux, an ICMP "port unreachable" that arrives later only raises EPOLLERR on the socket. tokio does not count that as readable, so `UdpSocket::recv` slept until the timeout instead of returning the refusal. async-io treated EPOLLERR as readable. The straight port (before the eager probe) showed the effect: the UDP sweep of the local host took 4.1 s instead of 1.0 s, because every closed port waited for the 500 ms timeout. With the eager probe it only hit closed ports whose ICMP arrived after the first receive. That is rare on the local host but the common case for any remote host, where it turned every closed port into a timeout. `recv_or_error` waits for `READABLE | ERROR` readiness and hands out the queued error (`take_error`), so a refused probe ends as soon as the ICMP arrives, as before. * ci(scan-benchmark): add a delayed host, fit Windows, compare misses What the first runs showed: - Only answers that arrive while the probe is still being sent were measured: on the loopback interface, refusals and ICMP errors are queued before connect()/send() returns. A remote host answers a round trip later, which is the path where tokio's UDP receive missed ICMP errors. On Linux the workflow now also sets up a host 5 ms away (a network namespace behind a netem-delayed veth pair, with ICMP rate limiting off, running its own listeners), and the benchmark sweeps it over TCP and UDP. - Windows retries a refused connection for about a second. With `-t 500`, 8,191 concurrent attempts made even the base miss listeners. Windows now uses the default timeout and sweeps 8,191 ports (2,047 for the 500-socket batch). - A build now fails the check only if it misses more listeners than the base does (any miss at all if the base misses none). Misses by the base are reported as a warning in the summary. - The macOS runner has no `net.inet.icmp.icmplim`, which failed the "describe" step, and caps descriptors at 10240, so the 65536 limit could not be set. The describe step can no longer fail the job, and 10240 is tried as well. * docs(address): say that parse_addresses must not run inside async code hickory's synchronous resolver runs its own tokio runtime, and tokio panics when a runtime is dropped inside an asynchronous context. That was already true before, but library users now have to run the scanner on tokio, so they are more likely to call `parse_addresses` from async code. Document the two safe ways: call it before starting the runtime (as the binary does) or through `spawn_blocking`. --------- Co-authored-by: Vrtgs <[email protected]>	2026-10-02 17:45:31 +09:00