-
Notifications
You must be signed in to change notification settings - Fork 184
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
fix(iroh-net): Improve direct connectivity establishment speed and re…
…liablity (#1984) ## Description This includes various fixes and improvements in holepunching behaviour, improving both how fast a direct connection is established and how reliably it is established. - Improve sending of call-me-maybe: this sometimes wasn't sent if there were no known addresses for an endpoint because no pings were sent and there was an active connection on via the derp path. Instead we now send it when needed, regardless of pings or active connections. To avoid sending it all the time when no direct connection can be established we only send it once every heartbeat cycle, i.e. every 5s. In the worst case (like when UDP pings get lost) this means a call-me-maybe will be sent after just under 2 heartbeat intervals, and should be regular every heartbeat interval afterwards. So in the face of packet loss this will still establish a connection eventually. - Not every scenario will result in a direct connection in both directions after each endpoint has sent one call-me-maybe request, because direct connections are asymmetric and each side has to receive their own disco pong before it will use the direct connection. To alleviate this and speed up the direct connection on the return path in cases were only one side manages to establish the direct path, this now also sends a ping message upon receipt of a ping. This opens the direct path much quicker in both directions. - When queuing a call-me-maybe and the last netcheck report is deemed too old, the call-me-maybe is not immediately sent. Instead a new netcheck is kicked off and the queued call-me-maybes should be sent once the report is in, so that they are sent with accurate local addresses. However they were never sent after the report finished. This is now fixed and they are sent after the report is ready. - When a ping timeout occurs, we were clearing the best_addr, i.e. the selected direct path, if the ping was for the same path as currently used. However that could have been for a timeout of an earlier ping that was still stopped by a firewall or NAT. It happens that a later ping is sent and receives a pong, before the timeout of that earlier ping. In that case we should not clear the direct path in use. - We used to prune addresses even if they were only just received from a call-me-maybe. This did not allow us to ping all the addresses from a call-me-maybe breaking hole punching. We take two measures: - Do not prune messages that were recently "alive", which means they received a ping, pong or call-me-maybe recently. - We increase the number of allowed inactive addresses. They used to be 100. If someone switches between several networks regularly, we would like to still know those previous networks as they might start working again. - When looking for a destination address for an endpoint, the addr_for_send() function uses un-confirmed UDP address if available. However if we were given an IPv6 address (probably via a ticket, effectively via add_node_addr()) we should only select the IPv6 address if netcheck repored we have working IPv6 ourself. - The netcheck report was wrongly overwriting whether an IP family was usable on dual stack hosts. Resulting in the magic socket being confused about which connectivity it had. This also begins to clean up some terminology: "endpoint" is used for many different things. Here the term "path" is consistently used when referring to a specific destination address of a node, whenter over the derper or a direct UDP socket. This naming cleanup however is not complete as that would obscure the fixes too much. More to be done later. Closes #1955 ## Notes & open questions This also changes the first address of our QuicMappedAddresses to start at 1. Not that 0 is reserved, but it is rather odd for people who are used to IPv4 to see 0 being a real node. And it's not like you're short of addresses in IPv6. ## Change checklist - [x] Self-review. - [x] Documentation updates if relevant. - [x] Tests if relevant. --------- Co-authored-by: dignifiedquire <me@dignifiedquire.com>
- Loading branch information
1 parent
983edcc
commit b173520
Showing
8 changed files
with
541 additions
and
248 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.