You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat(client): implement FastStart for early connection and background resolver discovery - #205
When configured with large resolver lists (e.g. 50–100+ endpoints), the client previously blocked session initialization and local proxy (SOCKS5/DNS) startup until 100% of all resolvers were synchronously probed for MTU.
This PR introduces FastStart:
When \RECHECK_INACTIVE_SERVERS_ENABLED = true\ (default), the initial MTU test completes early as soon as a minimal working set of resolvers (\min(TotalResolvers, max(1, RX_TX_WORKERS))) is validated.
The client connects and opens local proxy listeners immediately (~1–2s startup time).
The remaining unscanned resolvers remain in the pool as \inactive, where the existing background
unResolverHealthLoop\ discovers and reactivates them asynchronously without blocking user traffic.
When \RECHECK_INACTIVE_SERVERS_ENABLED = false, the legacy behavior is preserved (full 100% upfront scan).
Key Changes
**\internal/client/mtu.go**: Added early-exit condition to \RunInitialMTUTests\ bounded by \ argetValid, capped worker count during fast start, and added completion logs.
**\internal/client/fast_start_test.go**: Added comprehensive unit test suite (\TestRunInitialMTUTests_FastStartExitsEarly, \TestRunInitialMTUTests_FullScanWhenRecheckDisabled, \TestRunInitialMTUTests_FallbackWhenFewerResolversWork).
**\client_config.toml.simple\ & \README.MD**: Documented FastStart behavior under \RECHECK_INACTIVE_SERVERS_ENABLED.
Exported helper methods in \internal/config\ and \internal/udpserver\ (\DefaultClientConfig, \DefaultServerConfig, \Server.HandlePacket).
Verification
\go test -v ./internal/client -run TestRunInitialMTUTests\ -> PASS
Minimizes startup time (no need to scan the entire resolvers list), allows to have several hundreds of resolvers in the list without sacrificing connection time.
…speed qualification
- Add pipelined micro-burst speed prober to detect rate-limiting and burst packet loss
- Add candidate ranking score and top-N active pool selection (MAX_ACTIVE_RESOLVERS)
- Add initial balancer stat seeding (SeedBurstStats) and set Loss-Then-Latency (6) as default strategy
- Add micro-burst qualification on background inactive resolver reactivation
- Update client config, sample configs, and all 6 localized READMEs with full documentation
… resolvers for fast warm-start
- Preserved natural input order in LoadClientResolvers without forced sorting
- Added managed header block in client_resolvers.txt to persist top-performing resolvers across runs
- Added AUTO_SAVE_RANKED_RESOLVERS configuration option (default: true)
- Added Balancer.GetRankedEndpoints and Client.SaveRankedResolversToFile
- Auto-saves upon initial MTU test completion, pool optimization swaps, and graceful shutdown
- Added unit tests for order preservation, atomic file update, and endpoint ranking
- Synchronized documentation, CLI parameters, and samples across all README files
@masterking32 these precious times are passing by and the complete internet blackout resistance projects were not developed since filternet came back. i hope you do not abandon this project.
| `RESOLVER_BALANCING_STRATEGY` | `6` | `0..8` | Sceglie come vengono selezionati i resolver.<br>`0/2` = Round Robin, `1` = Random, `3` = Least Loss, `4` = Lowest Latency, `5` = Hybrid Score, `6` = Loss Then Latency (Predefinito), `7` = Least Loss Top Random, `8` = Least Loss Top Round Robin.<br>La modalità ibrida usa un punteggio combinato ponderato. La modalità loss-then-latency seleziona prima una rosa in base alla perdita, poi predilige la latenza inferiore all'interno di quella fascia e ruota tra i migliori candidati quasi equivalenti. La modalità top-random sceglie casualmente tra la migliore fascia di perdita affinché il carico non si concentri su un unico resolver. La modalità top-round-robin scorre la stessa migliore fascia di perdita con una rotazione deterministica. |
| `PACKET_DUPLICATION_COUNT` | `2` | limitato all'intervallo valido nel codice | Conteggio normale di duplicazione dei pacchetti in uscita.<br>Valori più alti aumentano il costo di traffico ma migliorano la sopravvivenza su collegamenti deboli. |
| `SETUP_PACKET_DUPLICATION_COUNT` | `2` | limitato all'intervallo valido nel codice | Simile a `PACKET_DUPLICATION_COUNT`, ma usato per i pacchetti sensibili al setup come la creazione degli stream e altri eventi di controllo critici. |
| `SETUP_PACKET_DUPLICATION_COUNT` | `2` | limitato all'intervallo valido nel codice | Simile a `PACKET_DUPLICATION_COUNT`, mas usato per i pacchetti sensibili al setup come la creazione degli stream e altri eventi di controllo critici. |
Apply resolver capacity limits after MTU burst qualification
internal/client/balancer.go:1379
This cap also applies during ApplyMTUProbeResult, before burst qualification. RunInitialMTUTests then qualifies only ActiveConnections(), excluding MTU-passing candidates placed on standby here. With MAX_ACTIVE_RESOLVERS=1 and FastStart disabled, a low-latency but rate-limited resolver can exclude a usable alternative, fail the burst test, and prevent startup despite a full MTU scan. Keep all MTU-passing candidates eligible for qualification, and apply the capacity limit after burst ranking.
Limit test parallelism to make cancellation assertions deterministic
internal/client/fast_start_test.go:90
The default MTUTestParallelism=16 allows all ten mock resolvers to run at once. All ten can commit successful results before cancellation is observed, making the later activeCount < 10 assertion fail under valid scheduling. Set parallelism to two so reaching the target necessarily leaves some endpoints untested.
Timestamp MTU responses while the packet train is sent
internal/client/micro_burst.go:184
Responses are read only after the entire paced send loop finishes, so this timestamp includes time already-arrived packets spent queued locally. With 32 packets spaced 2 ms apart, an immediate reply to the first query is measured roughly 62 ms late. These inflated round-trip times seed the balancer and affect ranking and promotion. Receive and timestamp responses while sending the train, synchronizing access to the per-query timing state.
Use monotonic traffic totals for periodic report gating
internal/client/runtime_stats.go:247
calculateTotalSentPackets sums adaptive scoring counters, not monotonic traffic totals: connectionStats.applyHalfLife halves them above 1,000 observations, and health rechecks can reseed them. After a decrease, this comparison suppresses periodic reports until the previous high-water mark is exceeded, potentially indefinitely despite ongoing traffic. Use a monotonic traffic counter or an interval activity flag for this gate instead of the decaying statistics.
c.log.Errorf("<red>No valid connections remaining after micro-burst qualification!</red>")
}
return ErrNoValidConnections
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
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.
Summary
When configured with large resolver lists (e.g. 50–100+ endpoints), the client previously blocked session initialization and local proxy (SOCKS5/DNS) startup until 100% of all resolvers were synchronously probed for MTU.
This PR introduces FastStart:
unResolverHealthLoop\ discovers and reactivates them asynchronously without blocking user traffic.
Key Changes
Verification