Disconnessioni WebSocket Tradovate: heartbeat e limite di 24 h
Un socket Tradovate che continua a disconnettersi quasi sempre dipende da tre errori risolvibili: heartbeat mancanti, ID di richiesta duplicati e una connessione mantenuta oltre il limite di 24 ore. Ecco ogni causa e la correzione esatta.
On This Page
- Cosa significa «il WebSocket Tradovate continua a disconnettersi»
- Principali cause delle disconnessioni del WebSocket Tradovate nel 2026
- 1. Nessun heartbeat (o uno in ritardo)
- 2. Le schede del browser limitano il suo timer
- 3. ID di richiesta duplicati
- 4. Invio troppo rapido di richieste
- 5. Raggiungimento del limite di 24 ore o token scaduto
- Come risolvere le disconnessioni del WebSocket Tradovate: passo dopo passo
- Risolvere gli heartbeat mancanti
- Risolvere la limitazione delle schede del browser
- Risolvere gli ID di richiesta duplicati
- Risolvere le inondazioni di richieste e il limite di 24 ore
- Tabella di risoluzione dei problemi
- Lo eviti con PickMyTrade
Trasmetta quotazioni in tempo reale di ES o NQ a una strategia automatizzata, e un WebSocket Tradovate che si disconnette in silenzio può lasciare una posizione non gestita per minuti prima ancora che lei se ne accorga. Il socket in tempo reale di Tradovate non perdona. Il server chiude una connessione inattiva entro circa 10 secondi se smette di sentire il suo client, e una singola connessione ha una durata massima misurata in ore, non in giorni. Quando un WebSocket Tradovate continua a disconnettersi, quasi sempre si tratta di tre errori risolvibili, heartbeat mancanti, ID di richiesta duplicati e una connessione mantenuta oltre il limite di 24 ore, più un quarto, l'inondazione del socket con richieste. Di seguito trova ogni causa, la correzione esatta e come instradare i suoi alert tramite PickMyTrade le evita del tutto la gestione del socket grezzo.
Checklist rapida per le disconnessioni del WebSocket Tradovate
- Invii un heartbeat ogni 2,5 secondi, un frame contenente un array vuoto
[], inviato dal client, mantiene aperto il socket. - Non si fidi di setInterval in una scheda del browser, le schede in background limitano i timer e lasciano il suo heartbeat a secco. Utilizzi un controllo del timestamp o un Web Worker.
- Assegni a ogni richiesta una i (ID di richiesta) unica e incrementale, non riutilizzi mai un ID intero sullo stesso socket.
- Dosi il ritmo delle sue richieste, inviare troppi frame troppo in fretta provoca una disconnessione lato server.
- Si riconnetta prima di ~24 ore, un singolo WebSocket Tradovate non è pensato per vivere indefinitamente, quindi pianifichi una riconnessione pulita.
- Rinnovi il token di accesso prima che scada, un token scaduto significa che la sua nuova autorizzazione alla riconnessione fallisce.
Cosa significa «il WebSocket Tradovate continua a disconnettersi»
Il protocollo WebSocket di Tradovate è per progettazione molto loquace. Dopo aver aperto il socket, il server invia un frame open (o), lei invia un frame authorize con il suo token di accesso e da quel momento entrambe le parti sono tenute a continuare a comunicare. Se il server non sente nulla dal suo client per circa 10 secondi, presume che la connessione sia morta e la chiude. Ecco perché un socket che “funzionava un attimo fa” cade nel momento in cui il suo codice smette di inviare frame.
Ecco il tranello che sorprende la maggior parte degli sviluppatori: una volta sottoscritto un feed di dati live, il server smette di inviarle i propri frame di heartbeat perché gli stessi messaggi in streaming dimostrano che il collegamento è attivo. Il suo client, però, deve comunque dimostrare che lui è attivo. Se il suo feed di dati diventa silenzioso, una sessione notturna lenta, un simbolo poco scambiato, e il suo client non invia i propri heartbeat, il server chiude il socket anche se nulla è “sbagliato”.
Oltre al timeout di inattività, mantenere una singola connessione aperta per più di 24 ore porta a disconnessioni. Quindi anche un client perfettamente corretto che invia heartbeat alla fine viene scollegato se non si riconnette mai. Comprendere questi due orologi, il timer di inattività di ~10 secondi e il limite di connessione di ~24 ore, è la chiave per un feed stabile.
Principali cause delle disconnessioni del WebSocket Tradovate nel 2026
1. Nessun heartbeat (o uno in ritardo)
Questa è la causa numero uno. Il suo client è responsabile dell'invio di un heartbeat ogni 2,5 secondi, un frame il cui testo è esattamente [], per evitare la chiusura per inattività. Se perde la finestra, il socket si chiude.
2. Le schede del browser limitano il suo timer
Se la sua app gira in un browser e lei guida gli heartbeat con setInterval o setTimeout, una scheda inattiva o in background vede i propri timer limitati dal browser. I suoi heartbeat arrivano in ritardo o si fermano del tutto, e il socket muore “senza motivo” nel momento in cui cambia scheda.
3. ID di richiesta duplicati
Ogni richiesta che invia porta un ID intero nel campo i. Se invia due richieste con lo stesso i sullo stesso socket, confonde l'associazione richiesta/risposta, il che può interrompere la connessione o lasciarla in attesa all'infinito di una risposta che non si risolve mai in modo pulito.
4. Invio troppo rapido di richieste
Se scarica una raffica di frame sul socket, ad esempio sottoscrivendo decine di simboli in un ciclo serrato o martellando modifiche agli ordini, può far scattare la protezione anti-flood di Tradovate e causare una disconnessione.
5. Raggiungimento del limite di 24 ore o token scaduto
Una connessione mantenuta aperta oltre circa 24 ore viene interrotta. Collegato a questo: il token di accesso alla base della sua sessione scade (i token di accesso di Tradovate hanno vita breve, nell'ordine di 90 minuti), quindi se tenta di autorizzare di nuovo un socket riconnesso con un token obsoleto, l'autenticazione fallisce e resta disconnesso.
Come risolvere le disconnessioni del WebSocket Tradovate: passo dopo passo
Risolvere gli heartbeat mancanti
Avviare una routine di heartbeat dopo l'autorizzazione
Non appena il suo socket è autorizzato, avvii una routine di heartbeat.
Inviare l'array vuoto con cadenza di 2,5 s
Ogni 2,5 secondi (2500 ms), invii un frame contenente un array vuoto [] usando il metodo send standard del WebSocket.
Continuare a inviare anche durante lo streaming
Continui a inviare heartbeat anche durante lo streaming dei dati di mercato, non dia per scontato che il silenzio del server significhi che il collegamento è sano. Quando i dati live fluiscono, il server smette di inviare i propri heartbeat, quindi i suoi sono l'unica cosa che mantiene aperto il socket durante i periodi tranquilli.
Trattarlo come «invia e dimentica»
Tratti l'heartbeat come «invia e dimentica». Non porta alcun ID di richiesta e non si aspetta alcuna risposta.
Risolvere la limitazione delle schede del browser
Smettere di affidarsi solo a setInterval
Smetta di affidarsi esclusivamente a setInterval / setTimeout per gli heartbeat in un browser.
Usare un approccio basato su timestamp
Utilizzi invece un approccio basato su timestamp: a ogni messaggio in arrivo, registri l'ora corrente e la confronti con l'ora dell'ultimo heartbeat. Se sono trascorsi più di 2500 ms, invii immediatamente un frame di heartbeat.
Spostare il timer fuori dal thread principale
Per le app che devono sopravvivere a lunghi periodi senza dati in arrivo in una scheda in background, sposti il timer in un Web Worker (che non viene limitato allo stesso modo), oppure esegua il socket in un processo Node.js lato server, dove il concetto di scheda inattiva non esiste affatto.
Risolvere gli ID di richiesta duplicati
Mantenere un unico contatore incrementale
Mantenga un unico contatore strettamente crescente per il campo i su ogni socket.
Riservare gli ID bassi alla configurazione
Riservi gli ID bassi che il protocollo usa per la configurazione (l'autorizzazione e la richiesta di sincronizzazione iniziale) e faccia partire il suo contatore generale sopra di essi.
Incrementare in modo atomico
Incrementi il contatore in modo atomico, così che due attività asincrone non possano mai ottenere lo stesso valore. In codice multi-thread o molto concorrente, protegga il contatore con un lock, una closure o una struttura thread-safe.
Non riutilizzare mai un ID in caso di nuovo tentativo
Non scriva mai a mano lo stesso ID due volte. Se ritenta una richiesta, assegni al nuovo tentativo un ID nuovo.
Risolvere le inondazioni di richieste e il limite di 24 ore
Limitare i frame in uscita
Metta le sue richieste in coda e le rilasci a un ritmo costante anziché in raffica. Distanziare sottoscrizioni e azioni sugli ordini la mantiene entro la tolleranza del socket.
Pianificare una riconnessione proattiva
Non aspetti la disconnessione delle ~24 ore. Si riconnetta secondo il suo calendario (ben entro le 24 ore), invii di nuovo il frame authorize e sottoscriva di nuovo i suoi feed, così che il passaggio sia fluido.
Aggiornare prima il token
Tenga traccia della scadenza del suo token di accesso e lo rinnovi prima che scada, così che la nuova autorizzazione alla riconnessione usi sempre un token valido. Le durate esatte dei token sono stabilite da Tradovate e possono cambiare, consulti la documentazione API attuale anziché scrivere un numero fisso nel codice.
Ripristinare automaticamente a ogni chiusura inattesa
Tratti ogni chiusura inattesa come un errore e si riprenda automaticamente. A meno che non stia spegnendo intenzionalmente, riapra il socket, si autorizzi di nuovo e sottoscriva di nuovo in automatico. Aggiunga un timeout alle risposte in sospeso, così che una richiesta bloccata non paralizzi mai l'intero client.
Tabella di risoluzione dei problemi
| Sintomo / errore | Cosa significa | Correzione |
|---|---|---|
| Il socket si chiude dopo ~10 secondi di silenzio | Nessun heartbeat del client; il server ha chiuso la connessione inattiva | Inviare un heartbeat con array vuoto [] ogni 2,5 s |
| Il feed muore non appena la scheda passa in background | Il browser ha limitato setInterval / setTimeout | Usare heartbeat basati su timestamp o un Web Worker |
| I dati live si fermano ma il socket «sembra» connesso | Il server ha smesso di inviare i propri heartbeat durante lo streaming; il client non ne ha inviati | Continuare a inviare heartbeat del client anche durante lo streaming |
| Le risposte non corrispondono o le richieste si bloccano | Valori interi i (ID di richiesta) duplicati | Usare un unico contatore di ID di richiesta atomico e incrementale |
| La connessione cade dopo una raffica di frame | Troppe richieste inviate troppo rapidamente | Mettere in coda e dosare le richieste in uscita |
| La connessione cade intorno alle 24 ore | Singola connessione mantenuta oltre la sua durata | Riconnettersi, autorizzarsi di nuovo e sottoscrivere di nuovo ben entro 24 h |
| La nuova autorizzazione fallisce dopo una riconnessione | Token di accesso scaduto | Rinnovare il token prima della scadenza, poi inviare di nuovo authorize |
Lo eviti con PickMyTrade
Se sta configurando l'automazione solo per far arrivare ordini su Tradovate, potrebbe non aver bisogno di gestire affatto un WebSocket grezzo. PickMyTrade prende i suoi alert TradingView e li consegna a Tradovate per lei, così che tempistica degli heartbeat, igiene degli ID di richiesta e logica di riconnessione restano dalla nostra parte:
- Salute della connessione gestita, la connessione a Tradovate viene mantenuta attiva e riconnessa per lei, così che i vuoti di heartbeat e il limite di 24 ore non raggiungano mai la sua strategia.
- Instradamento sicuro rispetto ai limiti di frequenza, gli alert vengono distanziati e messi in coda così che una raffica di segnali non inondi mai il socket fino alla disconnessione.
- Gestione di token & sessione, autenticazione e rinnovo sono gestiti dietro le quinte, così che un token scaduto non uccida mai in silenzio la sua automazione.
- Sincronizzazione multi-account, un alert viene replicato in modo pulito su più account Tradovate senza che lei debba destreggiarsi con un socket per account.
Operi senza rifiuti
Inizi la prova gratuita di 7 giorni, colleghi i suoi alert oggi stesso e operi senza rifiuti.
Inizi la prova gratuita di 7 giorniDomande frequenti
Ogni 2,5 secondi. Il client invia un frame contenente un array vuoto []. Se il server non sente nulla dal suo client per circa 10 secondi, chiude il socket per inattività.
È semplicemente il testo [], un array JSON vuoto, inviato con il metodo send standard del WebSocket. Non ha un ID di richiesta e non si aspetta alcuna risposta.
I browser limitano setInterval e setTimeout nelle schede in background, quindi gli heartbeat guidati da timer arrivano in ritardo e il socket va in timeout. Utilizzi un controllo del timestamp sui messaggi in arrivo, oppure sposti il timer in un Web Worker, in modo che gli heartbeat continuino a partire quando la scheda è inattiva.
Sì. Una volta sottoscritto un feed di dati, il server smette di inviare i propri heartbeat perché i messaggi in streaming dimostrano che il collegamento è attivo, ma il suo client deve comunque dimostrare di esserlo. Durante i periodi tranquilli senza dati in arrivo, i suoi heartbeat sono l'unica cosa che mantiene aperto il socket.
Ogni richiesta porta un intero i, e le risposte vengono associate a quell'ID. Riutilizzare un ID sullo stesso socket confonde questa associazione e può bloccare le richieste o far cadere la connessione. Utilizzi un unico contatore atomico che si incrementa a ogni richiesta.
Sì. Mantenere una connessione aperta oltre circa 24 ore porta alla disconnessione. Lo schema affidabile consiste nel riconnettersi secondo un proprio calendario, ben entro le 24 ore, quindi autorizzarsi di nuovo e sottoscrivere di nuovo, anziché aspettarsi che un singolo socket viva per sempre.
Probabilmente il suo token di accesso è scaduto. I token di accesso di Tradovate hanno vita breve, quindi rinnovi il token prima che scada e invii di nuovo il frame authorize con un token valido a ogni riconnessione. Le durate esatte dei token sono stabilite da Tradovate e possono cambiare, quindi le verifichi nella documentazione API attuale.
Se il suo obiettivo è semplicemente automatizzare gli ordini Tradovate da TradingView, utilizzi un bridge come PickMyTrade, in modo che salute della connessione, ritmo di invio e gestione dei token siano gestiti per lei, invece di mantenere personalmente un socket grezzo.
Questa guida ha esclusivamente finalità educative e informative e non costituisce consulenza finanziaria, di investimento o di trading. Operare in futures e in altri prodotti a leva comporta un rischio di perdita sostanziale e non è adatto a tutti gli investitori. PickMyTrade è una piattaforma di automazione indipendente di terze parti e non è affiliata, approvata né sponsorizzata da Tradovate, Inc. «Tradovate» e tutti i nomi, loghi e marchi correlati sono di proprietà dei rispettivi titolari. Le funzionalità e i passaggi della piattaforma cambiano nel tempo: confermi sempre la procedura aggiornata nella piattaforma e nella documentazione ufficiali di Tradovate prima di agire.