feat(iroh): streaming netreport#4400
Conversation
Move the probe-execution code into dedicated submodules: QUIC address discovery (connections, probes, relay-address resolution) into `qad`, HTTPS latency measurement into `https`, and captive portal detection into `captive_portal`. The reportgen actor keeps orchestrating; it now calls into these modules. This is a pure code move with no behavioral change. Item bodies are unchanged; only module paths and item visibility are adjusted. It prepares for the streaming net_report rewrite so that change stays focused on behavior rather than file reorganization.
|
Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/4400/docs/iroh/ Last updated: 2026-07-10T06:58:04Z |
0db5c01 to
119035b
Compare
|
Would this help with #4386 ? |
I have not looked at this PR but it depends on how it is done: The point of multiple QAD connections is that you can detect EIM from EDM NATs. So you need at least two to be able to tell. So the question is how many QAD connections is this keeping open at the same time? Do you gain anything from keeping only one open if you are on an EIM NAT? Probably not because when you change network you want to check again. |
|
Another consideration with this is that just keeping a connection open will not immediately give you a new QAD address when you move. The client needs to send something to the server before it can detect a new address. So this likely needs the ability to send a PING when iroh detects a network change. At this point there is nothing in terms of RTT that is between the streaming and non-streaming versions. Because QAD already sends the OBSERVED_ADDRESS at 0.5 RTT time. It could be however that it is less work to keep open an existing connection compared to always starting a new one. I suspect that would be the primary gain from this. (again, i've not looked at the PR itself yet) |
98f0cf1 to
13fcd0f
Compare
actor docs imporve
…ches Add net_report patchbay tests: a client behind a hard NAT (endpoint-dependent mapping) probing two relays must report mapping_varies_by_dest, an easy NAT must not, and the verdict must update correctly when the device replugs from one NAT to the other. The switch cases exercise the full re-detection path and guard against ReportHistory carrying a stale verdict forward. Generalize the relay test helper to spawn multiple named relays (lab_with_relays) and expose endpoint_builder. The patchbay cargo-make task now enables the unstable-net-report feature so Endpoint::net_report is available to the tests.
13fcd0f to
f3f0e15
Compare
3 participants
Description
(early draft, not yet fully reviewed)
motivation: make net report streaming so that we are informed about changing direct addrs immediately. but also keep the cycle-based model to have checkpoints where to potentially switch home relays. do this via a single long-running net report actor instead of a per-round actor managed in the socket state. also a preparation for reusing qad conns for h3 or the HTTPS probe TLS streams for the actual relay conns (this is not implemented yet).
best to look at commit-by-commit:
1 - only moving items around as preparation for the larger diff that follows. no other changes.
2 - the actual impl
3 - new patchbay tests
Breaking Changes
None
Notes & open questions
Change checklist
proposed change and wrote an as clear and concise description as
they could.
intented effect.