mirror of https://github.com/ospab/ostp.git
ospab
4a3fb8b944
Connecting over a mobile network took ~90s, and under worse conditions did
not complete at all. Three compounding causes, all in the address loop of
perform_handshake_with_id, which walks candidates strictly in order and burns
each one's full retry budget before touching the next:
- IPv6 was tried FIRST. Carriers routinely hand out IPv6 with no working
route and blackhole it rather than rejecting, so each AAAA record cost the
entire 4x1.2s budget with nothing to show; with several of them the
working IPv4 address was not reached for tens of seconds. The identical
ordering bug was already fixed on the server's outbound path and in the
UoT connect - the client's handshake was simply missed.
- The NAT64 prefix discovery lookup had no timeout. It only ever runs on
networks that are already misbehaving, exactly where a resolver can hang
for tens of seconds. Now bounded at 2s, falling back to the well-known
RFC 6052 prefix, which beats waiting.
- NAT64 was retried per failing IPv4 address, each time re-running that
lookup plus another four handshake attempts - for a path that either works
for the whole network or for none of it. Now attempted once.
Ordering alone is the dominant fix; the other two bound the tail.
|
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| test_udp.rs | ||