Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

fix(provider/selfhosted): server-advertised max connections and fix cpu dial spin

Aperta
  • Qualcosa non va?
#55 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
1-2 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend, networking

Direzione di ricerca

Start with selfhosted.go and trace openDataConnections; compare its connection management with localtunnel.go. Then inspect internal/server/protocol/protocol.go and handleControlConnection to follow how registration responses are built. Done means the response advertises the server buffer limit, the client caps and uses that limit to manage connections, and the idle client no longer spins CPU.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug

right now in selfhosted.go, openDataConnections has an infinite for loop that continuously dials the server without waiting:

for {
    conn, _ := dialer.DialContext(...)
    // sends TypeData
    go s.proxyRequest(ctx, conn, localPort)
}

once the server buffer fills up (10 conns), the server drops conn 11. since the dial itself succeeded, err == nil, so backoff never kicks in. the client just spins in a super tight loop dialing thousands of times per second and burning 100% cpu.

we wanted to fix this while keeping the client decoupled from whatever limit the server is configured with (so if someone changes VPS buffer to 5 or 25, client doesn't need a hardcoded update).

plan / what we should do:

  1. protocol:
    add max_connections (int) to TunnelResponse in internal/server/protocol/protocol.go.

  2. server:
    in handleControlConnection, send MaxConnections: defaultDataConnBuffer (or whatever buffer size is set to) in the response json when registering.

  3. client (selfhosted.go):
    mirror how localtunnel.go does it:

  • read resp.MaxConnections (clamp with a client ceiling like min(resp.MaxConnections, 30))
  • instead of the infinite dial loop, use openConnections to start that many handleConnection goroutines
  • each handleConnection holds 1 connection, calls proxyRequest, and only loops to redial a new one when that connection is done / closed
todo:
  • add max_connections to TunnelResponse
  • server sends its buffer size in registration response
  • client uses openConnections + handleConnection instead of unbounded for loop
  • test that idle selfhosted client doesn't spin cpu
Lingua principale
Go
Stelle
9
Fork
1
Merge medio
5h 57m
PR unite (30g)
15

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di kernelshard/expose

Tutte le issue di kernelshard/expose

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.