Skip to content

Conversation

@divagant-martian
Copy link

  • rename PunchMe to ReachOut
  • use new codes for transport parameter and frames
  • update frame fields
  • add the beginnings of nat traversal state
  • init state when the extension is negotiated
  • move the client side api away to deal with the error just once
  • handle removed and added frames
  • make some types public
  • move iroh_hp out of connection
  • thread adding addresses
  • thread removing addresses
  • include adding and removing frames in retransmission data
  • Send ADD_ADDRESS and REMOVE_ADDRESS frames
  • Add how to query the local nat traversal addresses.
  • Thread server updates about addresses
  • Boilerplate threading the nat traversal round call
  • Remove the path_id from the ReachOut frame
  • add retransmission fields for reach out frames
  • Send the reach out frames, probe server addresses
  • fix docs
  • Send the reach out frames
  • add fields to queue pending server-side challenges
  • Return the remotely advertised nat traversal addresses instead
  • modify the meaning of the transport parameter
  • Hook up id tryfrom
  • Queue server challenges
  • send rand data instead of path challenges
  • track sent reach outs in stats and sent frames
  • track sent add and remove address in stats and sent frames
  • Change APIs to set addresses
  • logging conventions
  • write 8 bytes, not 0
  • Update RttEstimator from path challenge responses

divagant-martian and others added 30 commits November 4, 2025 13:21
flub and others added 16 commits November 22, 2025 16:29
otherwise we're opening paths to/from the wrong remotes and packets
remotes do not match the PathData remote.
…enge resending (#178)

- Adds a timer to resend another path challenge if the old one was lost
and the path isn't validated.
- The resent challenges now have different tokens. We keep track of all
of them to verify incoming path responses.
- The logic for when to send a path challenge is simplified to only send
challenges when `send_new_challenge` is set to `true` (instead of
triggering *always* when we're in path validation mode)
We can receive a PATH_ABANDON frame for which we do not yet have any
PathData.  In this case we still want to abandon that path, and not
accidentally think we might be closing the last path.
- span for timers
- span for packets, this means we get path_id for some thing that are
  not on the path of processing frames.  the recv span can now lose
  the path_id.
matheus23 and others added 4 commits November 26, 2025 13:35
…d` instead of `Connection::max_path_id` (#183)

This adds a previously failing test case that best illustrates the
problem.

Here's a picture anyways:
<img width="1733" height="1044" alt="image"
src="https://github.com/user-attachments/assets/684d66de-f80a-4561-93a2-7391e5372734"
/>

When the server receives a `MAX_PATH_ID` frame and agrees to increase
it, it'll increase it after sending a `MAX_PATH_ID` frame itself.
Now, from the server's perspective the maximum path ID might be set to
14 (a value I saw in practice).
Then it starts issuing NEW_CONNECTION_ID frames with path IDs up to what
it thinks is the max path id.
However, these two datagrams might get reordered. This is what we
synthetically make happen in the test `issue_max_path_id_reordered`.
Then, the client will receive newer NEW_CONNECTION_ID frames while it
still thinks the max path ID might be something like 12 and promptly
close the connection with a protocol violation.

The fix I propose is to be more lenient when reading incoming packets.
The `NEW_CONNECTION_ID` frame we got IMO is *fine* because we've already
sent out a `MAX_PATH_ID` frame with 14. The fact that the other side
hasn't sent us a `MAX_PATH_ID` frame is kind of secondary.
The other possible fix would be to delay the remote using any higher
path IDs until it made sure the `MAX_PATH_ID` frame was acknowledged. I
think this adds unnecessary delays.

The specification doesn't really seem to agree with me on this.
Section 4 says:
>   Receipt of multipath-specific frames that use a path ID that is
>   greater than the announced Maximum Paths value in the MAX_PATH_ID
>   frame or in the initial_max_path_id transport parameter, if no
>   MAX_PATH_ID frame was received yet, MUST be treated as a connection
>   error of type PROTOCOL_VIOLATION.

I interpret the `MAX_PATH_ID` frames as the ones that are *received*,
due to it referring to having received them or not in the next sentence.
This means the situation from the picture above would be the
connection's flow according to the specification. (But I think that's a
specification bug.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: 🏗 In progress

Development

Successfully merging this pull request may close these issues.

5 participants