github anton48/vk-turn-proxy-ios v1.0-build34
v1.0 Build 34 — Event-driven slot wakeup, three-value Pool stat, CredCache fix

latest releases: v1.0-build351, v1.0-build350, v1.0-build349...
3 months ago

Highlights

Five commits since v1.0-build29. Each one is small and individually validated against the day's logs.

Reliability — event-driven slot wakeup (Variant B)

credPool now broadcasts a close-and-replace signal channel whenever a slot transitions toward usable: a fresh cred lands in a slot (via seedSlot, tryFill, or get's Phase 2 fetch), or a release lowers the active count below the per-slot cap on a slot that is fresh AND not VK-saturated. runConnection's retry select arms include the channel, so conns parked in "no slot available" backoff wake within milliseconds of any pool-state change instead of sleeping out their 2-7s short-delay (or 30s-3min dormancy) random timer.

Demonstrated in vpn.wifi.8.log on 2026-05-02: when slot 3 finally got a fresh cred via VK fetch, 9 parked conns acquired it within 21 ms total — versus the 5-7 s average random-walk recovery without the broadcast.

UX — three-value Pool stat

The Pool box in StatsView now reads fresh / with-creds / total instead of filled / total. The middle number exposes the previously hidden state where a slot's cred has crossed its 30-min expiry buffer (or is in pending / saturated state) — the slot stops handing out new allocations but existing conns on it stay alive until VK invalidates them. So the user can tell apart "cred is expired and gone" from "cred is here but currently inert".

UX — Uptime fix on app re-attach

TunnelManager.observeStatus now stamps connectedAt if the initial status read returns .connected, not just on future transitions. Without this, opening the app while a tunnel was already running steady-state showed "Connected" alongside Uptime "—" forever.

Reliability — CredCache expiryGuard alignment

CredCache.expiryGuard raised from 60 s to 30 min (1800 s), matching the Go-side credExpiryBuffer. Earlier the cache could return a borderline-expiring cred (~6 min remaining) as the pre-bootstrap seed; the extension would immediately reject it, falling into a Phase 2 fetch INSIDE the tunnel context where iOS preliminary tunnel routes had already broken the WebView's main-app internet — surfacing as a blank captcha sheet and a bootstrap timeout.

vpn.wifi.7.log shows the regression and vpn.wifi.8.log shows the fix: same disk state, captcha auto-solves in main-app context, fresh long-lived cred seeded, tunnel up clean.

Empirical validation

  • 9 conns acquired a freshly-fetched slot in 21 ms (Variant B working as designed).
  • Pre-bootstrap probe completes in ~15 s under VK hostile mode when no usable disk cred exists.
  • Pool stat correctly reports 4/5/6 after one of two empty slots gets fetched, leaving slot 4 in lameduck (cred present but past expiry buffer) until VK eventually cooperates on a replacement fetch.

Defaults from build 29 (unchanged)

  • NumConnections: 30
  • credPoolCooldown: 150 s
  • Persistent TURN creds across launches
  • Freeze-aware watchdog
  • Slider auto-solver
  • Settings → Backup & Restore

Known issues

  • VK hostile mode (slider returning status:ERROR for hours at a time) is unaffected by anything client-side; pre-bootstrap probe and background grower will fall back to WebView, but new fetches stall when the user can't / doesn't solve a captcha.
  • iOS-stuck-VPN after xcrun devicectl install over a running extension — dev-flow only, workaround is manual Disconnect before install.

Don't miss a new vk-turn-proxy-ios release

NewReleases is sending notifications on new releases.