feat(iroh)!: encapsulate the quinn::TransportConfig to enforce certain minimums when used with multipath#3721
Conversation
|
Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/3721/docs/iroh/ Last updated: 2025-12-04T15:02:31Z |
b38720a to
9ccd81c
Compare
quinn::TransportConfig to enforce certain minimums when used with multipathquinn::TransportConfig to enforce certain minimums when used with multipath
I don't really know why |
…aults returns errors when a user tries to set those defaults with values that makes iroh work worse
9ccd81c to
5e42916
Compare
| MAX_MULTIPATH_PATHS + 1 | ||
| ); | ||
| } | ||
| self.0.max_concurrent_multipath_paths(max_concurrent); |
There was a problem hiding this comment.
I think we should ignore the user's setting if they set it too small. if max_concurrent < MAX_MULTIPATH_PATHS + 1 we print a warning saying we're ignoring their setting and actually set self.0.max_concurrent_multipath_paths(MAX_MULTIPATH_PATHS + 1).
Otherwise it is too easy to get hard-to-debug issues, where we'll only figure things out much too late. The issues we will get from ignoring the user-provided value will be much easier to understand and then we can figure out what the usecases are and how to support them.
Same for the others.
Description
This PR encapsulates the
quinn::TransportConfigin a new struct calledQuicTransportConfig. It has all of the same methods as thequinn::TransportConfig, but the follow methods will log warnings if the user given values make iroh + multipath sub-optimal:HEARTBEAT_INTERVALmsPATH_MAX_IDLE_TIMEOUTmsMAX_MULTIPATH + 1MAX_MULTIPATHThese values are also set properly by default when creating a
QuicTransportConfig.quinn encapsulation/co-location
Created a new mod
quicand co-located all the quinn exports there.This would be the mod where we do any future encapsulation.
Note: the
StaticConfigstruct is a private struct that still usesquinn::TransportConfigdirectly.Second note: theConnectConfigwasClone, and no longer is. This is due to a weird tension in our encapsulation ofquinn::TransportConfig. The quinn APIs typically expect anArc<quinn::TransportConfig>, however if we store anArcof thequinn::TransportConfiginQuicTransportConfig, then we can't actually mutate any fields inside it, unless we also put it in aMutex. The "slickest" way to ensure that we did not need to store anArc<quinn::TransportConfig>, was to ensure that we didn't have APIs that required cloning or Arc-ing theQuicTransportConfigitself (quinn::TransportConfig is also not clone).It's possible this is terribly annoying for our users, so if someone else has an ergonomic way of handling this, please let me know.waiting for PR n0-computer/noq#213 to merge, then this can be mergedmergedthird note: I adjusted theHEARTBEAT_INTERVALandPATH_MAX_IDLE_TIMEOUTto be numerical values rather thanDurations, so they can be read-able in the documentation.closes #3635
Breaking Changes
irohQuinnTransportConfigrenamed toQuicTransportConfig& is nowCloneConnectOptions::transport_config: Option<Arc<quinn::TransportConfig>>-> `ConnectOptions::transport_config: OptionConnectOptions::with_transport_config(mut self, transport_config: Arc<quinn::TransportConfig>)-> `ConnectOptions::with_transport_config(mut self, transport_config: QuicTransportConfig)Open Questions