feat(iroh)!: replace Incoming::local_ip with Incoming::local_addr#4182
feat(iroh)!: replace Incoming::local_ip with Incoming::local_addr#4182dignifiedquire merged 8 commits intomainfrom
Conversation
This allows custom transports to show expose their incoming address as well, and makes this API more future proof for transports in general. Closes #3886
|
Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/4182/docs/iroh/ Last updated: 2026-04-30T08:08:26Z |
| /// The remote custom address. | ||
| remote: CustomAddr, | ||
| /// The local custom address, if the transport reports one. | ||
| local: Option<CustomAddr>, |
There was a problem hiding this comment.
I like the public API, but not sure I like the implementation. The type is entirely different for Custom now, essentially it is a 4-tuple that describes the network path.
There was a problem hiding this comment.
@flub feel better with the latest version?
|
Here is a variant that leaves Addr alone: #4185 |
…sses. (#4185) ## Description Introduce a struct RecvInfo that has local and remote addresses. This is an internal struct unless you enable custom transports. It internally has remote as Addr, but the only public way to construct it is via new, which takes only a CustomAddr. So the custom transports API becomes a bit more tight. We could have a separate struct for the custom transports, but that would mean that we would have to copy in a hot path. ## Breaking Changes <!-- Optional, if there are any breaking changes document them, including how to migrate older code. --> ## Notes & open questions <!-- Any notes, remarks or open questions you have to make about the PR. --> ## Change checklist <!-- Remove any that are not relevant. --> - [ ] Self-review. - [ ] Documentation updates following the [style guide](https://rust-lang.github.io/rfcs/1574-more-api-documentation-conventions.html#appendix-a-full-conventions-text), if relevant. - [ ] Tests if relevant. - [ ] All breaking changes documented. - [ ] List all breaking changes in the above "Breaking Changes" section. - [ ] Open an issue or PR on any number0 repos that are affected by this breaking change. Give guidance on how the updates should be handled or do the actual updates themselves. The major ones are: - [ ] [`quic-rpc`](https://github.com/n0-computer/quic-rpc) - [ ] [`iroh-gossip`](https://github.com/n0-computer/iroh-gossip) - [ ] [`iroh-blobs`](https://github.com/n0-computer/iroh-blobs) - [ ] [`dumbpipe`](https://github.com/n0-computer/dumbpipe) - [ ] [`sendme`](https://github.com/n0-computer/sendme)
| if let Some(local) = recv_info.local() { | ||
| let local_mapped = self.mapped_addrs.custom_addrs.get(local); | ||
| noq_meta.dst_ip = Some(local_mapped.private_socket_addr().ip()); | ||
| } |
There was a problem hiding this comment.
How does this work? MappedAddrs::custom_addrs is a map from a custom addr to an IPv6 ULA. Both the local and remote custom addresses get looked up there so they both get their own IPv6 ULA. Where do they get inserted into this map?
There was a problem hiding this comment.
I could have sworn I had code for this, maybe it got lost..
There was a problem hiding this comment.
happening in socket.rs 640, get also inserts
There was a problem hiding this comment.
So I guess I find it a bit confusing that both the remote and local addrs are in the same map. Would it not make sense to use different ULA subnets for the local and remote addresses? That would also make identifying them in logs etc a bit more easily.
I'd even be tempted to map each different custom transport to a different ULA subnet, since I believe you have a unique numerical identifier for it anyway. But I guess that's out of scope here as that already exists.
AFAIK the ULA mapping is not part of a real contract, other than that it is unique. So changing the address mapping should be something we're allowed to do post 1.0 so perhaps this isn't overly important.
There was a problem hiding this comment.
what is ULA? 😅
I didn't want to introduce too many new maps, which is why I kept them in the same map for now
There was a problem hiding this comment.
IPv6 Unique Local Addresses. It is a range of IPv6 addresses that you can assign yourself. We use them for all the mapped addresses and use a subnet per mapping purpose.
3 participants
Description
This allows custom transports to show expose their incoming address as well, and makes this API more future proof for transports in general.
Closes #3886
Breaking Changes
Incoming::local_ip(useIncoming::local_addrnow)