-
Notifications
You must be signed in to change notification settings - Fork 334
feat(iroh)!: newtype ServerConfig and RetryError, organize the quinn re-exports
#3757
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/3757/docs/iroh/ Last updated: 2025-12-18T18:35:03Z |
flub
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really nice to get all the imports cleaned up, thank you for slogging through that!
flub
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upstream's ARC's around the transport config and server config were carefully constructed so that you could do a accept_with in a loop with customised config and all you ever had to do was increment the ref count on the Arc. And we now have a full clone of a struct every time. That's pretty unfortunate.
I've not tried to see if it can be solved or not... but it might be worth seeing if that could be possible?
The Endpoint::create_server_config method is fine I think, both in location and name.
|
@flub My only proposed "solution" to the The builder structs would contain un-arc-ed versions of the inner quinn types, and the built versions would contain arc-d versions that can no longer be edited. |
|
@flub latest commit does the split between builder types for I think it works out fine. What is interesting here is that in quinn those types are pretty opaque, only allowing visibility into very few fields after they've been edited, so it doesn't bloat the API tooooo much. If you think this is the way to go, I'll add docs. |
flub
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed the builder works quite well for this! I'm fine with using this approach.
476f40c to
433db37
Compare
|
Okay so latest changes:
|
…3774) ## Description Builds on the work done in #3757 to make types more or less public. - makes `CreateHandleError` public - makes `IncomingFuture` public - makes `net_report::GetRelayAddrError` and `net_report::MeasureHttpsLatencyError` more private - removes unused `IpPorts` struct --------- Co-authored-by: “ramfox” <“kasey@n0.computer”>
f89d177 to
1d60d30
Compare
|
thanks for doing this, the builder code reads so much nicer now |
1d60d30 to
afc4b06
Compare
`ServerConfig` is used in the public API in `Incoming::accept_with`. `quinn::ServerConfig` takes a `TransportConfig`. However, we want to maintain control over the `TransportConfig` fields, so we new typed it to `QuicTransportConfig`. So, we needed to new type `quinn::ServerConfig`, which ensures setting the `QuicTransportConfig` correctly. This also organizes the quinn imports and labels where each type comes from.
…pes that are re-exported by iroh
…tConfig`, to enable arc-ing the inner quinn structs
afc4b06 to
69e22d9
Compare
Description
Incoming::retryreturns aRetryError, which you can turn back into aquinn::Incoming. We want thatquinn::Incomingto instead be aniroh::endpoint::Incoming. This PR fixes that.Incoming::accept_withtakes aquinn::ServerConfig, however thequinn::ServerConfigallows you to override thequinn::TransportConfig, which we have new typed toQuicTransportConfig. So, this PR new typesquinn::ServerConfigtoquic::ServerConfig, and ensures that thequinn::TransportConfigis set appropriately for multipath use.This PR also explicitly comments on each quinn export and labels what type uses that export and where it enters the public iroh API.
Breaking Changes
iroh:- changed
-
Incoming::retrynow returns aniroh::endpoint::RetryError, rather than aquinn::RetryError-
Incoming::accept_withnow takes airoh::endpoint::ServerConfig, rather than aquinn::ServerConfig-
iroh::endpoint::QuicTransportConfighas no more "set" methods, those have been moved toiroh::endpoint::QuicTransportConfigBuilder-
iroh:endpoint::QuicTransportConfig::builder()returns a defaultiroh::endpoint:: QuicTransportConfigBuilder- removed
- removed
quinn::ServerConfig(useiroh::endpoint::ServerConfig)- removed
quinn::RetryError(useiroh::endpoint::RetryError)- added
- added
iroh::endpoint::ServerConfigBuilder- added
iroh::endpoint::ServerConfig- added
iroh::endpoint::RetryErrorNotes & open questions
Okay. So. I impl'd all of the methods one-to-one from
quinn::ServerConfig, but I think there are a bunch of fields we may want to restrict folks from messing with when they useIncoming::accept_with, as currently, they can use this API to replace our normal TlsConfig entirely.I'm also unsure if there are any other bits in here (for example the
quinn::ServerConfig::migratefield) that may interfere with expected multipath usage.My proposal would be to either eliminate the
Incoming::accept_withmethod entirely (therefore removing the need to publically export theServerConfig), or reduceServerConfigin scope so that only fields that will not interfere with "business as usual" for multipath/iroh remain.Change checklist