WebSocket Tradovate « Connection to Remote Host Lost »

Quand votre bot diffuse des cotations ES ou NQ en continu, rien ne tue une stratégie plus vite qu'un WebSocket Tradovate qui meurt discrètement avec “Connection to remote host was lost.” C'est l'un des casse-têtes les plus courants de l'API Tradovate : le socket fonctionne sans problème pendant des heures, puis tombe, très souvent autour de la barre des 24 heures, et emporte avec lui vos données de marché en direct et l'acheminement des ordres. Parfois cela apparaît comme une fermeture WebSocket brute (code 1006, “abnormal closure”). Parfois cela ressemble à une déconnexion massive. Parfois, c'est simplement un flux mort qui ne lève jamais d'exception.

Il n'existe pas de réglage magique unique qui règle cela. Ce qui maintient réellement un socket en vie, c'est un ensemble d'habitudes qui fonctionnent ensemble : des heartbeats de 2,5 secondes, la reconnexion automatique, le renouvellement du jeton et la rotation de la connexion avant qu'elle ne devienne périmée. PickMyTrade intègre cette logique de reconnexion et de réautorisation, de sorte que vos alertes TradingView continuent d'atteindre Tradovate même quand un socket artisanal serait discrètement tombé.

Ce que signifie « Connection to Remote Host Was Lost »

“Connection to remote host was lost” est la façon dont Tradovate vous indique que le WebSocket vers ses serveurs est fermé et n'est plus utilisable. C'est un événement de niveau transport, pas un ordre rejeté ni une mauvaise requête. Le tuyau lui-même a disparu. En coulisses, cela se manifeste généralement par une fermeture WebSocket anormale (code de fermeture 1006), c'est-à-dire une connexion tombée sans handshake de fermeture propre, si bien que votre client ne peut pas toujours vous dire exactement pourquoi.

Voici ce qui piège les gens : une connexion perdue est normale et attendue sur un flux de longue durée. Les réseaux vacillent, les répartiteurs de charge se recyclent, les sockets inactifs sont élagués, les jetons expirent et les très longues sessions sont renouvelées côté serveur. Même un client parfaitement bien élevé qui diffuse des données en direct peut perdre le socket après assez d'heures de fonctionnement. Le but n'est donc pas un socket qui ne tombe jamais, c'est impossible. Le but est un client qui remarque la coupure instantanément et se rétablit tout seul, sans que vous ayez à le surveiller.

Cette distinction compte pour le risque. Si votre flux meurt en silence et que votre code continue de se croire connecté, vous pouvez manquer des exécutions, manquer des déclenchements de stop ou envoyer des ordres sur une vue périmée du marché. Traitez chaque WebSocket comme jetable et chaque déconnexion comme un événement de routine à gérer, pas comme une urgence.

Principales causes d'un WebSocket Tradovate interrompu

1. Heartbeats manqués (délai d'inactivité du serveur)

C'est de loin la cause la plus courante. Le protocole WebSocket de Tradovate exige que le client envoie un heartbeat toutes les 2,5 secondes, une trame dont le texte est un tableau vide, [], pour prouver qu'il est toujours en vie. Si le serveur reste 2,5 secondes sans vous entendre et ne vous diffuse pas activement de données, il traite le client comme inactif et ferme la connexion. Et voici le piège : tant que le serveur pousse activement des messages (par exemple un abonnement aux données de marché très actif), il n'enverra pas ses propres heartbeats ; maintenir le flux des trames [] incombe donc entièrement à votre client.

2. Bridage du navigateur / des minuteurs

Si vous développez dans le navigateur et planifiez les heartbeats avec setInterval ou setTimeout, vous tombez dans un piège subtil : les navigateurs brident les minuteurs dans les onglets en arrière-plan ou inactifs, étirant votre intervalle de 2,5 secondes à plusieurs secondes. Dès qu'il dépasse la fenêtre, le serveur ferme le socket. Ne vous appuyez pas sur setInterval, calez plutôt vos heartbeats sur le dernier message réellement reçu.

3. Expiration du jeton d'accès

Votre WebSocket est autorisé une fois avec un jeton d'accès, et ce jeton a une durée de vie limitée, d'environ 90 minutes depuis sa création selon la documentation API de Tradovate. Quand le jeton derrière une connexion active expire, la connexion n'est plus authentifiée et peut être coupée. Un client de longue durée qui ne renouvelle jamais son jeton verra le socket mourir à intervalle prévisible.

4. Connexions de longue durée au-delà de ~24 heures

Maintenir une connexion plus de 24 heures est en soi une cause reconnue de coupures. Même avec des heartbeats parfaits et un jeton frais, un socket ouvert depuis environ un jour est un candidat de choix au recyclage côté serveur. C'est pourquoi une connexion brute qui “a fonctionné tout l'après-midi” meurt mystérieusement pendant la nuit.

5. Tempêtes de reconnexion et limite de sessions

Quand un socket tombe, le code naïf martèle souvent le serveur de tentatives de reconnexion immédiates et successives. Cela peut déclencher les limites de débit de requêtes de Tradovate et aggraver les choses, et se réauthentifier à répétition (au lieu de renouveler) peut vous faire buter sur le plafond de sessions simultanées. Le résultat est un client coincé dans une boucle de reconnexion qui ne se stabilise jamais.

Comment réparer une connexion WebSocket Tradovate perdue : pas à pas

Envoyez un heartbeat toutes les 2,5 secondes, de la bonne façon

Cette seule habitude résout la majorité des signalements “connection to remote host was lost”, car elle satisfait directement la règle de délai d'inactivité du serveur.

Ajoutez une logique de reconnexion automatique et de réabonnement

Renouvelez le jeton d'accès et réautorisez le socket

Confirmez que l'accès API est activé et que vous êtes dans la limite de sessions

Faites tourner proactivement la connexion avant 24 heures

Plutôt que d'attendre que le serveur coupe un socket vieux d'un jour, prenez les devants. Sur minuteur, confortablement sous le plafond de ~24 heures, fermez proprement votre WebSocket existant et ouvrez-en un nouveau avec un jeton fraîchement renouvelé, puis réautorisez et réabonnez-vous. Comme votre chemin de reconnexion existe déjà (vous l'avez construit à l'étape précédente), un cycle planifié n'est qu'une version contrôlée de la même routine. Il transforme une déconnexion surprise à 3 h du matin en un rafraîchissement planifié et invisible.

Tableau de dépannage

Évitez cela avec PickMyTrade

Si votre but est simplement de faire parvenir de façon fiable les alertes TradingView à Tradovate, vous n'avez pas à construire et surveiller vous-même toute cette tuyauterie de sockets. PickMyTrade se place entre TradingView et Tradovate et maintient la connexion en bonne santé pour vous.

• Logique de reconnexion gérée, reconnexion, réautorisation et réabonnement automatiques à chaque coupure, de sorte qu'un socket perdu se rétablit sans que vous ayez à écrire ou maintenir le code.
• Renouvellement du jeton intégré, les sessions sont rafraîchies avant leur expiration, ce qui garde la connexion authentifiée au lieu de mourir à l'horloge du jeton de ~90 minutes.
• Rotation des connexions, les connexions de longue durée sont recyclées de façon proactive, afin que la coupure à ~24 heures ne surprenne jamais votre automatisation hors ligne.
• Acheminement respectueux des limites de débit, les reconnexions et le flux d'ordres sont espacés pour respecter les limites de Tradovate, évitant les blocages par tempête de reconnexion qui affligent les sockets bruts.