Closed
Conversation
- Reexport guts of magicsock for implementing custom transports - Add comments to new public fields and structs
packets are being sent and received, but we still get a timeout connecting
It's got its own subnet [0, 3] so we can go back from an IPV6 addr to a UserMappedAddr
|
Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/3707/docs/iroh/ Last updated: 2025-12-10T16:22:19Z |
c792b95 to
5eea792
Compare
a7a4e2c to
e6b3aab
Compare
479652f to
232524f
Compare
github-merge-queue bot
pushed a commit
that referenced
this pull request
Mar 5, 2026
## Description Adds user defined transports. Transports have to impl a dynable trait, currently named CustomTransport. Implementing this requires implementing another dynable trait CustomSender. Creating a transport requires implementing yet another dynable trait CustomTransportFactory. A custom addr is just an opaque blob with an u64 tranport id. Small blobs will be inlined, but that is an implementation detail. Formatting currently is "<id hex>-<data hex>" Replaces #3707 ## Breaking Changes <!-- Optional, if there are any breaking changes document them, including how to migrate older code. --> ## Notes & open questions - Question: encoding of custom addrs in DNS records. - Option 1: addr=1_a1b2c3 (tries to parse first as SocketAddr then as custom addr) - Option 2: custom=1_a1b2c3 (separate IrohAttr::Custom) - ~~Question: Feature gate or not? User transports require exposing a bit more of the guts, e.g. transmit fields, so we might want to put this behind a feature flag that is documented to be not part of the stable API.~~ - ~~Question: Path selection.~~ ~~Currently in select_best_path we never select an user path. For some reason it still works, but we probably should put in some logic there.~~ ```rust Some((transports::Addr::User(_), _)) => { // todo: when should we select an user path? None } ``` - DRY the different mapped addrs? ~~We could DRY the 2 differnet mapped addrs a bit more. But once you start with this you get into a rabbit hole. Should relay transports just be a special kind of custom transport? If we could abstract the logic when to choose the relay, this might work. Maybe this is best left for later.~~ Update: path selection is now taken care of. Basically each path gets a 2-tuple consisting of primary/secondary and biased rtt, then sort and take the best. There is an API to add a bias for each addr type and also to configure for each transport if it is a transport of last resort. Here is how to bias a transport: ```rust Endpoint::builder() .transport_bias( AddrKind::Custom(TEST_TRANSPORT_ID), TransportBias::primary().with_rtt_advantage(CUSTOM_TRANSPORT_RTT_ADVANTAGE)) .build().await?; ``` I also added some tests to make sure custom transports work if the ip transport is enabled.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds user defined transports.
Transports have to impl a dynable trait, currently named UserTransport. Implementing this requires implementing another dynable trait UserSender. Creating a transport requires implementing yet another dynable trait UserTransportConfig (possibly to be renamed to UserTransportFactory?, it's not a config).
An user addr is just an opaque blob with an u64 tranport id. Small blobs will be inlined, but that is an implementation detail.
Breaking Changes
Notes & open questions
Open questions:
Change checklist
quic-rpciroh-gossipiroh-blobsdumbpipesendme