Fall back to alternative OR or Dir port if the current fails

When a client (or relay, when that time comes(*)) fails to connect to an OR port it should try using another OR port for the relay it's trying to connect to, if there is one.

(*) relay to relay as well as relay to authority connections

changed milestone to %Tor: unspecified

added address-handling component::core tor/tor ipv6 milestone::Tor: unspecified parent::17835 points::1 priority::medium robustness severity::normal single-onion status::new tor-client tor-hs type::enhancement labels

Trac:
Keywords: ipv6 deleted, ipv6 tor-client added

Trac:
Component: Tor Client to Tor

Trac:
Milestone: Tor: 0.2.4.x-final to Tor: unspecified

Make #15228 (moved) the parent to collect all fallback directory tickets in one place

Trac:
Parent: N/A to #15228 (moved)

Trac:
Severity: N/A to Normal
Parent: #15228 (moved) to #17811 (moved)
Sponsor: N/A to N/A

Fortunately, this ticket is not as necessary as it used to be, because Tor picks a small set of guards / directory guards that it can connect to and sticks with them. Many OR (and some Dir) destinations are actually tunneled via tor, so only the guards' ORPorts actually matter.

One design for this is like #4483 (moved):

• try to connect to the preferred ORPort (address/port)
• when the connection fails, or if it hasn't succeeded after N seconds, try to connect to the other ORPort (if any)
• Close all other connection attempts to the same server when the first connects

We might need to do this for some DirPort connections as well.

I think it's OK for us to just try another directory server on failure as we typically do. But if we had reasons to pick that specific server, and we were making a direct connection to it (do we ever do this?), then using the alternate DirPort (address) would be good.

We discovered in #18348 (moved) that we'll definitely need to do this for DirPorts as well. As it's the same code, and some DirPort connections are tunneled, it's best handled in the same place.

Trac:
Summary: Fall back to alternative OR port if the current fails to Fall back to alternative OR or Dir port if the current fails

Trac:
Keywords: ipv6 tor-client deleted, ipv6 tor-client robustness address-handling added
Priority: Medium to Low
Reviewer: N/A to N/A

Existing client guard code already implements this feature by trying another guard if one fails. #24403 (moved) will make relays retry IPv4 and IPv6 when an EXTEND has both addresses. #17835 (moved) should do the same for client connections to entry nodes. (If a specific entry node is required (single onion services only?), we should choose an available address at random. If not, we should do what the existing guard code does, and choose another entry node at random - because we are more likely to succeed than a retry.)

Trac:
Sponsor: N/A to SponsorV-can
Priority: Low to Medium
Keywords: ipv6 tor-client robustness address-handling deleted, ipv6 tor-client tor-hs single-onion robustness address-handling added
Parent: #17811 (moved) to #17835 (moved)
Points: N/A to 1

Removing sponsor V as we do not have more time to include this tickets in the sponsor.

Removing sponsor from tickets that we do not have time to fit in the remain of this sponsorship.

Trac:
Sponsor: SponsorV-can to N/A

changed time estimate to 8h

mentioned in issue #6773 (moved)

mentioned in issue #15228 (moved)

mentioned in issue #17840 (moved)

mentioned in issue #18348 (moved)

mentioned in issue #22781 (moved)

moved to tpo/core/tor#6772 (closed)

mentioned in issue tpo/core/tor#6773 (closed)