Tradovate MD: “Connection Forcibly Closed” quotidiano

Ormai conosce lo schema. Tutto scorre bene durante l'apertura attiva, poi il mercato si calma e il feed collassa con An existing connection was forcibly closed by the remote host. A volte i grafici si riprendono dopo un ricaricamento rapido. A volte l'intero feed di dati di mercato si spegne e la schermata di accesso OAuth ricompare, chiedendo di accedere di nuovo. E non è casuale, tende a colpire nello stesso tratto tranquillo della giornata. Ecco cosa significa davvero quell'errore, perché i contratti tranquilli lo innescano più spesso di quelli veloci, e lo schema esatto di riconnessione più ri-autenticazione che evita che una disconnessione forzata quotidiana si trasformi in un fill mancato.

Cosa significa davvero “Connection Forcibly Closed”

La frase An existing connection was forcibly closed by the remote host è un messaggio dei socket Windows, errore WinSock 10054, scritto anche come WSAECONNRESET. In termini semplici, l'altro lato ha inviato un pacchetto TCP RST: ha chiuso la connessione di colpo invece di seguire il gentile handshake di chiusura. Il suo client non ha deciso di riagganciare. Qualcosa dall'altra parte lo ha fatto per lei.

Quel “qualcosa” può essere il server di Tradovate, un load balancer, un proxy o un timer di sessione in qualsiasi punto del percorso. Sul socket dei dati di mercato (MD) la lettura pratica è semplice: la connessione era sana, poi è sparita in un passaggio brusco, senza una chiusura pulita che desse al suo codice un avviso ordinato. Trattandosi di un reset duro, il suo normale gestore di chiusura ha appena il tempo di girare, e qualsiasi scrittura in coda su quel socket fallisce subito dopo.

Il cambio di mentalità chiave è questo: una chiusura forzata non è un difetto che può correggere fino a farlo sparire. I reset TCP accadono, le reti hanno intoppi, i timer a monte scattano, le sessioni scadono. La soluzione duratura non è impedire ogni chiusura. È costruire una connessione che nota la caduta all'istante e si ricostruisce da sola prima ancora che lei arrivi a toccare il mouse.

Le principali cause della disconnessione forzata quotidiana nel 2026

1. Timeout di inattività durante i periodi di mercato tranquilli

Questa è la causa principale dello schema “stessa ora ogni giorno”. Quando un contratto si prosciuga, un future agricolo con poco volume a metà sessione, o qualsiasi simbolo nella calma overnight, le quotazioni smettono di arrivare. Un socket che trasporta solo tick di dati di mercato appare ora inattivo per qualsiasi timer presente sul percorso. Senza un heartbeat costante del client che dimostri il contrario, quel timer alla fine decide che la connessione è obsoleta e la chiude forzatamente. Più il mercato è tranquillo, più questo colpisce, motivo per cui le cadute si concentrano nelle parti lente della sua giornata di trading.

2. Nessun heartbeat, o un heartbeat in ritardo

Il feed in tempo reale di Tradovate si aspetta che il client invii un piccolo frame di keep-alive, con contenuto testuale [], circa ogni 2,5 secondi. Una volta che i dati live iniziano a scorrere, il server smette di inviare i propri heartbeat, quindi non può fare affidamento sul traffico in entrata per mantenere la linea aperta. Se salta il frame, o lo lascia scivolare oltre la finestra, la connessione viene contrassegnata come morta. Su un contratto tranquillo non c'è traffico di tick a mascherare un heartbeat mancato, quindi un keep-alive trascurato viene scoperto rapidamente.

3. La sessione e il token dietro il socket sono scaduti

Quando il socket muore, muore anche la sessione autorizzata che vi transita sopra. Questo è il motivo per cui la schermata di accesso OAuth ricompare: il client non ha più una sessione attiva su cui trasmettere, quindi la riporta al login. Peggiora se il suo token di accesso era già vicino alla scadenza: anche una riconnessione istantanea non può autorizzarsi con un token obsoleto, quindi il nuovo socket fallisce allo stesso modo e resta bloccato in un ciclo di login.

4. Riconnettersi in modo troppo aggressivo (e finire limitati per frequenza)

Quando nota le cadute, l'istinto è riconnettersi rapidamente, riprovare ogni tre o cinque secondi finché non funziona. Questo si ritorce contro. Aprire connessioni così rapidamente fa scattare il limite di frequenza di Tradovate e le procura un 429 Too Many Requests, che la blocca ancora più duramente. Un loop di riconnessione serrato trasforma un piccolo intoppo di mercato tranquillo in un'interruzione autoinflitta.

5. Limiti di sessione e connessioni di lunga durata

Ogni nuovo accesso avvia una nuova sessione lato server, ed è previsto un limite al numero di sessioni simultanee, se ne avvia troppe, le più vecchie vengono chiuse senza preavviso. Anche le connessioni non sono pensate per durare per sempre; tenere un socket aperto per un'intera giornata tende a farlo cadere da solo. Su un conto prop o di valutazione, le regole di sessione e riconnessione possono essere più rigide e variare in base alla società e alla dimensione del conto, verifichi le regole attuali della sua società invece di presumere che si applichino i valori predefiniti retail.

Come risolvere la disconnessione forzata quotidiana: passo dopo passo

Soluzione 1: mantenga il socket attivo con un heartbeat reale

Gli heartbeat sono la sua prima linea di difesa, e contano di più esattamente quando il mercato è tranquillo:

• Dopo che il socket si apre e lei si è autorizzato, avvii una routine di keep-alive che gira sul proprio orologio, non in base ai tick in arrivo.
• A ogni ciclo, invii un frame il cui testo è [], il keep-alive a parentesi vuote.
• Punti a una cadenza leggermente inferiore a 2,5 secondi così che un frame un po' in ritardo arrivi comunque entro la finestra.
• Non lo programmi con un semplice timer del browser in una scheda in background, questi vengono limitati, l'intervallo slitta e il socket cade comunque. Esegua la connessione lato server o in un worker così che il timer resti affidabile.

Soluzione 2: rilevi la chiusura e si riconnetta con backoff

Poiché una chiusura forzata prima o poi accadrà comunque, incapsuli il socket così che una caduta lo ricostruisca automaticamente, con attenzione:

• Gestisca il ciclo di vita. Metta il socket dentro un'unica classe o funzione responsabile di crearlo, smontarlo e ricrearlo, così che ci sia un unico punto che reagisce a una chiusura.
• Si riconnetta alla chiusura, non rianimi. Apra un socket completamente nuovo invece di provare a rianimare quello morto.
• Applichi un backoff esponenziale. Inizi intorno a un secondo, raddoppi l'attesa dopo ogni tentativo fallito, la limiti a circa sessanta secondi, e aggiunga uno 0–10 % di jitter casuale così che una flotta di client non riprovi in modo sincronizzato. Questo è ciò che la tiene lontano dal blocco 429.
• Limiti i tentativi così che un'interruzione genuina non giri all'infinito, e mostri un errore chiaro invece di continuare in loop silenziosamente.

Soluzione 3: si ri-autorizzi con un token nuovo così che la schermata OAuth non torni mai

La riconnessione è solo metà del lavoro, il nuovo socket ha comunque bisogno di una sessione valida:

• Rinnovi il token in modo proattivo. Il token di accesso ha una durata limitata (comunemente indicata intorno ai 60–90 minuti, e cambia nel tempo, confermi il valore attuale nella documentazione API). Lo rinnovi con largo anticipo rispetto alla scadenza usando l'endpoint di rinnovo token; una linea guida comune è rinnovarlo circa 15 minuti prima che scada.
• Tenga sempre pronto un token fresco. Quando si verifica una caduta, autorizzi il nuovo socket con un token di cui sa già che è valido, non con quello che potrebbe essere appena scaduto.
• Riutilizzi la sessione quando può per non esaurire il suo limite di sessioni simultanee e non far saltare le sue altre connessioni.
• Fatto correttamente, il client si ri-autorizza in background e la schermata di login non compare mai.

Soluzione 4: si riabboni a ogni feed dopo la riconnessione

Un nuovo socket parte da zero, senza sottoscrizioni, senza sincronizzazione, quindi ripristini lo stato prima di fidarsi dei dati:

• Rinvii la richiesta di sincronizzazione così che lo stato del conto e degli ordini torni aggiornato.
• Si riabboni a ogni simbolo e feed di dati di mercato che stava seguendo; il nuovo socket non ne conosce nessuno.
• Attenda che il socket segnali di essere realmente aperto prima di inviare qualsiasi cosa, così da non scrivere in una connessione semiaperta.
• Registri il codice di chiusura e il motivo a ogni caduta, nell'arco di una settimana le indicherà quale finestra tranquilla continua a uccidere il feed.

Tabella di risoluzione dei problemi

Lo previene con PickMyTrade

PickMyTrade si colloca tra i suoi alert di TradingView e Tradovate ed esegue lo strato di connessione come servizio gestito lato server, così che una chiusura forzata quotidiana venga gestita ben prima che possa costarle un trade:

• Heartbeat gestiti, invia il frame di keep-alive con una cadenza stabile lato server, così che un contratto tranquillo non appaia mai inattivo a un timer a monte.
• Riconnessione automatica con backoff, rileva la chiusura forzata, riapre il socket con backoff esponenziale e jitter, e resta lontano dal blocco 429.
• Ri-autenticazione OAuth in background, rinnova il token prima della scadenza e si ri-autorizza automaticamente, così che la schermata di login non la interrompa mai.
• Riabbonamento automatico e sincronizzazione multi-account, ripristina ogni feed dopo una riconnessione e mantiene ogni account connesso in streaming, così che una caduta non lasci mai indietro un account.