WebSocket di Tradovate «Connection to Remote Host Lost»

Quando il suo bot trasmette quotazioni ES o NQ ventiquattr'ore su ventiquattro, nulla uccide una strategia più in fretta di un WebSocket di Tradovate che muore silenziosamente con “Connection to remote host was lost.” È uno dei mal di testa più comuni dell'API di Tradovate: il socket funziona senza problemi per ore, poi cade, molto spesso intorno alle 24 ore, e si porta via i suoi dati di mercato in tempo reale e l'instradamento degli ordini. A volte lo vede come una chiusura WebSocket grezza (codice 1006, “abnormal closure”). A volte sembra una disconnessione di massa. A volte è semplicemente un feed morto che non solleva mai un'eccezione.

Non esiste una singola impostazione magica che risolva il problema. Ciò che tiene davvero in vita un socket è un insieme di abitudini che lavorano insieme: heartbeat da 2,5 secondi, riconnessione automatica, rinnovo del token e rotazione della connessione prima che diventi obsoleta. PickMyTrade integra questa logica di riconnessione e riautorizzazione, così i suoi alert di TradingView continuano a raggiungere Tradovate anche quando un socket artigianale sarebbe silenziosamente caduto.

Cosa significa «Connection to Remote Host Was Lost»

“Connection to remote host was lost” è il modo in cui Tradovate le comunica che il WebSocket verso i suoi server è chiuso e non più utilizzabile. È un evento a livello di trasporto, non un ordine rifiutato né una richiesta errata. È la condotta stessa a essere sparita. Sotto il cofano, di solito si presenta come una chiusura WebSocket anomala (codice di chiusura 1006), cioè una connessione caduta senza un handshake di chiusura pulito, quindi il suo client non sempre può dirle esattamente perché.

Ecco la parte che mette in difficoltà: una connessione persa è normale e attesa su un feed di lunga durata. Le reti ballano, i load balancer si riciclano, i socket inattivi vengono potati, i token scadono e le sessioni molto lunghe vengono ciclate lato server. Anche un client perfettamente ben educato che trasmette dati in tempo reale può perdere il socket dopo abbastanza ore di attività. Quindi l'obiettivo non è un socket che non cade mai, è impossibile. L'obiettivo è un client che si accorga subito della caduta e si riprenda da solo, senza doverlo sorvegliare.

Questa distinzione conta per il rischio. Se il suo feed muore in silenzio e il suo codice continua a credersi connesso, può perdere fill, mancare l'attivazione degli stop o inviare ordini su una vista obsoleta del mercato. Tratti ogni WebSocket come usa e getta e ogni disconnessione come un evento di routine da gestire, non come un'emergenza.

Principali cause di un WebSocket di Tradovate interrotto

1. Heartbeat mancati (timeout di inattività del server)

È di gran lunga la causa più comune. Il protocollo WebSocket di Tradovate richiede che il client invii un heartbeat ogni 2,5 secondi, un frame il cui testo è un array vuoto, [], per dimostrare di essere ancora vivo. Se il server resta 2,5 secondi senza sentirla e non le sta trasmettendo attivamente dati, tratta il client come inattivo e chiude la connessione. E qui sta il problema: finché il server sta spingendo attivamente messaggi (ad esempio un'iscrizione ai dati di mercato molto attiva), non invierà i propri heartbeat, quindi mantenere in flusso i frame [] spetta interamente al suo client.

2. Limitazione del browser / dei timer

Se sviluppa nel browser e pianifica gli heartbeat con setInterval o setTimeout, cade in una trappola sottile: i browser limitano i timer nelle schede in background o inattive, dilatando il suo intervallo di 2,5 secondi a diversi secondi. Nel momento in cui supera la finestra, il server chiude il socket. Non si appoggi a setInterval, cadenzi invece i suoi heartbeat a partire dall'ultimo messaggio effettivamente ricevuto.

3. Scadenza del token di accesso

Il suo WebSocket viene autorizzato una volta con un token di accesso, e quel token ha una durata limitata, di circa 90 minuti dalla creazione secondo la documentazione API di Tradovate. Quando il token dietro una connessione attiva scade, la connessione non è più autenticata e può essere interrotta. Un client in esecuzione prolungata che non rinnova mai il token vedrà il socket morire con una cadenza prevedibile.

4. Connessioni di lunga durata oltre ~24 ore

Mantenere una connessione per più di 24 ore è di per sé una causa riconosciuta di cadute. Anche con heartbeat perfetti e un token fresco, un socket aperto da circa un giorno è un candidato ideale al riciclo lato server. Ecco perché una connessione grezza che “ha funzionato tutto il pomeriggio” muore misteriosamente durante la notte.

5. Tempeste di riconnessione e limite di sessioni

Quando un socket cade, il codice ingenuo spesso martella il server con tentativi di riconnessione immediati e consecutivi. Ciò può far scattare i limiti di frequenza delle richieste di Tradovate e peggiorare le cose, e riautenticarsi ripetutamente (invece di rinnovare) può farla scontrare con il tetto di sessioni simultanee. Il risultato è un client bloccato in un ciclo di riconnessione che non si stabilizza mai.

Come riparare una connessione WebSocket di Tradovate persa: passo dopo passo

Invii un heartbeat ogni 2,5 secondi, nel modo giusto

Questa sola abitudine risolve la maggior parte delle segnalazioni “connection to remote host was lost”, perché soddisfa direttamente la regola del timeout di inattività del server.

Aggiunga logica di riconnessione automatica e nuova iscrizione

Rinnovi il token di accesso e riautorizzi il socket

Confermi che l'accesso API sia abilitato e di essere entro il limite di sessioni

Cicli in modo proattivo la connessione prima delle 24 ore

Invece di aspettare che il server tronchi un socket vecchio di un giorno, lo anticipi. Con un timer, comodamente sotto il tetto di ~24 ore, chiuda in modo pulito il suo WebSocket esistente e ne apra uno nuovo con un token appena rinnovato, quindi riautorizzi e si iscriva di nuovo. Poiché il suo percorso di riconnessione esiste già (lo ha costruito nel passaggio precedente), un ciclo programmato è solo una versione controllata della stessa routine. Trasforma una disconnessione a sorpresa alle 3 di notte in un aggiornamento pianificato e invisibile.

Tabella di risoluzione dei problemi

Lo prevenga con PickMyTrade

Se il suo obiettivo è semplicemente far arrivare in modo affidabile gli alert di TradingView a Tradovate, non deve costruire e sorvegliare da sé tutta questa infrastruttura di socket. PickMyTrade si colloca tra TradingView e Tradovate e mantiene sana la connessione per Lei.

• Logica di riconnessione gestita, riconnessione, riautorizzazione e nuova iscrizione automatiche a ogni caduta, così un socket perso si riprende senza che debba scrivere o mantenere il codice.
• Rinnovo del token integrato, le sessioni vengono aggiornate prima della scadenza, mantenendo la connessione autenticata invece di morire con l'orologio del token da ~90 minuti.
• Rotazione delle connessioni, le connessioni di lunga durata vengono riciclate in modo proattivo, così la caduta a ~24 ore non coglie mai la sua automazione offline.
• Instradamento sicuro rispetto ai limiti di frequenza, riconnessioni e flusso degli ordini sono distanziati per rispettare i limiti di Tradovate, evitando i blocchi da tempesta di riconnessione che affliggono i socket grezzi.