Déconnexions WebSocket Tradovate : heartbeats et limite de 24 h
Un socket Tradovate qui se déconnecte sans cesse tient presque toujours à trois erreurs corrigeables : des heartbeats manquants, des identifiants de requête en double et une connexion maintenue au-delà de la limite de 24 heures. Voici chaque cause et le correctif exact.
On This Page
- Ce que signifie « le WebSocket Tradovate se déconnecte sans cesse »
- Principales causes des déconnexions WebSocket Tradovate en 2026
- 1. Pas de heartbeat (ou un heartbeat tardif)
- 2. Les onglets du navigateur brident votre minuterie
- 3. Identifiants de requête en double
- 4. Envoi de requêtes trop rapide
- 5. Limite de 24 heures atteinte ou jeton expiré
- Comment corriger les déconnexions WebSocket Tradovate : pas à pas
- Corriger les heartbeats manquants
- Corriger le bridage des onglets du navigateur
- Corriger les identifiants de requête en double
- Corriger les inondations de requêtes et la limite de 24 heures
- Tableau de dépannage
- Évitez cela avec PickMyTrade
Diffusez des cotations ES ou NQ en direct vers une stratégie automatisée, et un WebSocket Tradovate qui se déconnecte silencieusement peut laisser une position sans surveillance pendant des minutes avant même que vous ne vous en aperceviez. Le socket temps réel de Tradovate est impitoyable. Le serveur ferme une connexion inactive en environ 10 secondes s'il cesse d'entendre votre client, et une connexion unique a une durée de vie stricte mesurée en heures, pas en jours. Lorsqu'un WebSocket Tradovate se déconnecte sans cesse, cela tient presque toujours à trois erreurs corrigeables, des heartbeats manquants, des identifiants de requête en double et une connexion maintenue au-delà de la limite de 24 heures, plus une quatrième, l'inondation du socket de requêtes. Vous trouverez ci-dessous chaque cause, le correctif exact, et comment l'acheminement de vos alertes via PickMyTrade vous évite entièrement la plomberie de socket brute.
Liste de contrôle rapide pour les déconnexions WebSocket Tradovate
- Envoyez un heartbeat toutes les 2,5 secondes, une trame contenant un tableau vide
[], envoyée par le client, maintient le socket ouvert. - Ne vous fiez pas à setInterval dans un onglet de navigateur, les onglets en arrière-plan brident les minuteries et privent votre heartbeat. Utilisez une vérification d'horodatage ou un Web Worker.
- Donnez à chaque requête un i (identifiant de requête) unique et incrémental, ne réutilisez jamais un identifiant entier sur le même socket.
- Rythmez vos requêtes, envoyer trop de trames trop vite déclenche une déconnexion côté serveur.
- Reconnectez-vous avant ~24 heures, un WebSocket Tradovate unique n'est pas fait pour vivre indéfiniment, planifiez donc une reconnexion propre.
- Renouvelez le jeton d'accès avant son expiration, un jeton expiré signifie que votre réautorisation lors de la reconnexion échoue.
Ce que signifie « le WebSocket Tradovate se déconnecte sans cesse »
Le protocole WebSocket de Tradovate est bavard par conception. Une fois le socket ouvert, le serveur envoie une trame open (o), vous envoyez une trame authorize avec votre jeton d'accès, et à partir de là les deux parties sont censées continuer à échanger. Si le serveur n'entend rien de votre client pendant environ 10 secondes, il suppose que la connexion est morte et la ferme. C'est pourquoi un socket qui “fonctionnait il y a une seconde” tombe dès que votre code cesse d'envoyer des trames.
Voici le piège qui surprend la plupart des développeurs : une fois abonné à un flux de données en direct, le serveur cesse de vous envoyer ses propres trames de heartbeat, car les messages de streaming prouvent eux-mêmes que la liaison est active. Votre client, lui, doit toujours prouver qu'il est actif. Si votre flux de données devient silencieux, une séance nocturne calme, un symbole peu échangé, et que votre client n'envoie pas ses propres heartbeats, le serveur ferme le socket alors que rien n'est “anormal”.
En plus du délai d'inactivité, maintenir une seule connexion ouverte pendant plus de 24 heures entraîne des déconnexions. Même un client parfaitement sage qui envoie des heartbeats finit donc par être déconnecté s'il ne se reconnecte jamais. Comprendre ces deux horloges, la minuterie d'inactivité d'environ 10 secondes et le plafond de connexion d'environ 24 heures, est la clé d'un flux stable.
Principales causes des déconnexions WebSocket Tradovate en 2026
1. Pas de heartbeat (ou un heartbeat tardif)
C'est la cause numéro un. Votre client est chargé d'envoyer un heartbeat toutes les 2,5 secondes, une trame dont le texte est exactement [], afin d'éviter d'être fermé pour inactivité. Si vous manquez la fenêtre, le socket se ferme.
2. Les onglets du navigateur brident votre minuterie
Si votre application s'exécute dans un navigateur et que vous pilotez les heartbeats avec setInterval ou setTimeout, un onglet inactif ou en arrière-plan voit ses minuteries bridées par le navigateur. Vos heartbeats arrivent en retard ou s'arrêtent complètement, et le socket meurt “sans raison” dès que vous changez d'onglet.
3. Identifiants de requête en double
Chaque requête que vous envoyez porte un identifiant entier dans son champ i. Envoyez deux requêtes avec le même i sur le même socket et vous perturbez l'association requête/réponse, ce qui peut casser la connexion ou vous laisser attendre indéfiniment une réponse qui ne se résout jamais proprement.
4. Envoi de requêtes trop rapide
Si vous lancez une rafale de trames sur le socket, par exemple en vous abonnant à des dizaines de symboles dans une boucle serrée ou en martelant des modifications d'ordres, vous pouvez déclencher la protection anti-inondation de Tradovate et provoquer une déconnexion.
5. Limite de 24 heures atteinte ou jeton expiré
Une connexion maintenue ouverte au-delà d'environ 24 heures est coupée. Dans le même ordre d'idées, le jeton d'accès de votre session expire (les jetons d'accès Tradovate ont une durée de vie courte, de l'ordre de 90 minutes) : si vous tentez de réautoriser un socket reconnecté avec un jeton périmé, l'authentification échoue et vous restez déconnecté.
Comment corriger les déconnexions WebSocket Tradovate : pas à pas
Corriger les heartbeats manquants
Démarrer une routine de heartbeat après l'autorisation
Dès que votre socket est autorisé, démarrez une routine de heartbeat.
Envoyer le tableau vide toutes les 2,5 s
Toutes les 2,5 secondes (2500 ms), envoyez une trame contenant un tableau vide [] avec la méthode send standard du WebSocket.
Continuer d'envoyer même pendant le streaming
Continuez d'envoyer des heartbeats même pendant la diffusion de données de marché, ne supposez pas que le silence du serveur signifie que la liaison est saine. Lorsque des données en direct circulent, le serveur cesse d'envoyer ses propres heartbeats, si bien que les vôtres sont la seule chose qui maintient le socket ouvert pendant les périodes calmes.
Le traiter en « envoyer et oublier »
Traitez le heartbeat en « envoyer et oublier ». Il ne porte aucun identifiant de requête et n'attend aucune réponse.
Corriger le bridage des onglets du navigateur
Ne plus compter uniquement sur setInterval
Cessez de vous reposer uniquement sur setInterval / setTimeout pour les heartbeats dans un navigateur.
Utiliser une approche basée sur l'horodatage
Utilisez plutôt une approche basée sur l'horodatage : à chaque message entrant, enregistrez l'heure actuelle et comparez-la à l'heure du dernier heartbeat. Si plus de 2500 ms se sont écoulées, envoyez immédiatement une trame de heartbeat.
Sortir la minuterie du thread principal
Pour les applications qui doivent survivre à de longues périodes sans données entrantes dans un onglet en arrière-plan, déplacez la minuterie dans un Web Worker (qui n'est pas bridé de la même façon), ou exécutez le socket dans un processus Node.js côté serveur, où la notion d'onglet inactif n'existe pas.
Corriger les identifiants de requête en double
Maintenir un seul compteur incrémental
Maintenez un seul compteur strictement croissant pour le champ i sur chaque socket.
Réserver les identifiants bas pour la configuration
Réservez les identifiants bas utilisés par le protocole pour la configuration (l'autorisation et la requête de synchronisation initiale) et faites démarrer votre compteur général au-dessus.
Incrémenter de façon atomique
Incrémentez le compteur de façon atomique afin que deux tâches asynchrones ne puissent jamais obtenir la même valeur. Dans un code multithread ou fortement concurrent, protégez le compteur par un verrou, une fermeture (closure) ou une structure thread-safe.
Ne jamais réutiliser un identifiant lors d'une nouvelle tentative
N'écrivez jamais le même identifiant deux fois à la main. Si vous retentez une requête, donnez à la nouvelle tentative un identifiant neuf.
Corriger les inondations de requêtes et la limite de 24 heures
Limiter les trames sortantes
Mettez vos requêtes en file d'attente et libérez-les à un rythme régulier au lieu de les envoyer en rafale. Espacer les abonnements et les actions sur ordres vous maintient sous la tolérance du socket.
Planifier une reconnexion proactive
N'attendez pas la coupure d'environ 24 heures. Reconnectez-vous selon votre propre calendrier (bien en deçà de 24 heures), renvoyez la trame authorize et réabonnez-vous à vos flux pour que la transition soit fluide.
Renouveler d'abord le jeton
Suivez l'expiration de votre jeton d'accès et renouvelez-le avant qu'il n'expire, afin que la réautorisation lors de la reconnexion utilise toujours un jeton valide. Les durées exactes des jetons sont fixées par Tradovate et peuvent changer, consultez la documentation actuelle de l'API plutôt que de coder un nombre en dur.
Récupérer automatiquement après chaque fermeture inattendue
Traitez chaque fermeture inattendue comme une erreur et récupérez automatiquement. Sauf si vous arrêtez volontairement, rouvrez le socket, réautorisez-vous et réabonnez-vous automatiquement. Ajoutez un délai d'attente sur les réponses en attente afin qu'une requête bloquée ne paralyse jamais tout votre client.
Tableau de dépannage
| Symptôme / erreur | Ce que cela signifie | Correctif |
|---|---|---|
| Le socket se ferme après ~10 secondes de silence | Pas de heartbeat client ; le serveur a fermé la connexion inactive | Envoyer un heartbeat à tableau vide [] toutes les 2,5 s |
| Le flux s'arrête dès que l'onglet passe en arrière-plan | Le navigateur a bridé setInterval / setTimeout | Utiliser des heartbeats basés sur l'horodatage ou un Web Worker |
| Les données en direct s'arrêtent mais le socket « semble » connecté | Le serveur a cessé ses propres heartbeats pendant le streaming ; le client n'en a envoyé aucun | Continuer d'envoyer les heartbeats du client même pendant le streaming |
| Les réponses ne correspondent pas ou les requêtes se bloquent | Valeurs entières i (identifiant de requête) en double | Utiliser un seul compteur d'identifiants de requête atomique et incrémental |
| La connexion tombe après une rafale de trames | Trop de requêtes envoyées trop rapidement | Mettre en file d'attente et rythmer les requêtes sortantes |
| La connexion tombe autour de la marque des 24 heures | Connexion unique maintenue au-delà de sa durée de vie | Se reconnecter, se réautoriser et se réabonner bien en deçà de 24 h |
| La réautorisation échoue après une reconnexion | Jeton d'accès expiré | Renouveler le jeton avant son expiration, puis renvoyer authorize |
Évitez cela avec PickMyTrade
Si vous mettez en place l'automatisation uniquement pour acheminer des ordres vers Tradovate, vous n'avez peut-être pas besoin de gérer un WebSocket brut du tout. PickMyTrade prend vos alertes TradingView et les livre à Tradovate pour vous, de sorte que le timing des heartbeats, l'hygiène des identifiants de requête et la logique de reconnexion restent de notre côté :
- Santé de la connexion gérée, la connexion à Tradovate est maintenue active et reconnectée pour vous, de sorte que les trous de heartbeat et le plafond de 24 heures n'atteignent jamais votre stratégie.
- Routage respectueux des limites de débit, les alertes sont rythmées et mises en file d'attente afin qu'une rafale de signaux n'inonde jamais le socket jusqu'à la déconnexion.
- Gestion des jetons & des sessions, l'authentification et le renouvellement sont gérés en coulisses, de sorte qu'un jeton expiré ne tue jamais silencieusement votre automatisation.
- Synchronisation multi-comptes, une alerte est répliquée proprement sur plusieurs comptes Tradovate sans que vous ayez à jongler avec un socket par compte.
Tradez sans rejet
Commencez votre essai gratuit de 7 jours, reliez vos alertes dès aujourd'hui et tradez sans rejet.
Commencez votre essai gratuit de 7 joursQuestions fréquentes
Toutes les 2,5 secondes. Le client envoie une trame contenant un tableau vide []. Si le serveur n'entend rien de votre client pendant environ 10 secondes, il ferme le socket pour inactivité.
C'est simplement le texte [], un tableau JSON vide, envoyé avec la méthode send standard du WebSocket. Il n'a pas d'identifiant de requête et n'attend aucune réponse.
Les navigateurs brident setInterval et setTimeout dans les onglets en arrière-plan : les heartbeats pilotés par minuterie arrivent donc en retard et le socket expire. Utilisez une vérification d'horodatage sur les messages entrants, ou déplacez la minuterie dans un Web Worker, afin que les heartbeats continuent d'être émis lorsque l'onglet est inactif.
Oui. Une fois abonné à un flux de données, le serveur cesse d'envoyer ses propres heartbeats, car les messages de streaming prouvent que la liaison est active, mais votre client doit toujours prouver qu'il l'est. Pendant les périodes calmes sans données entrantes, vos heartbeats sont la seule chose qui maintient le socket ouvert.
Chaque requête porte un entier i, et les réponses sont associées à cet identifiant. Réutiliser un identifiant sur le même socket perturbe cette association et peut bloquer des requêtes ou couper la connexion. Utilisez un seul compteur atomique qui s'incrémente à chaque requête.
Oui. Maintenir une connexion ouverte au-delà d'environ 24 heures entraîne une déconnexion. Le schéma fiable consiste à vous reconnecter selon votre propre calendrier, bien en deçà de 24 heures, puis à vous réautoriser et à vous réabonner, plutôt que d'attendre qu'un seul socket vive éternellement.
Votre jeton d'accès a probablement expiré. Les jetons d'accès Tradovate ont une durée de vie courte : renouvelez donc le jeton avant son expiration et renvoyez la trame authorize avec un jeton valide à chaque reconnexion. Les durées exactes des jetons sont fixées par Tradovate et peuvent changer, confirmez-les donc dans la documentation actuelle de l'API.
Si votre objectif est simplement d'automatiser les ordres Tradovate depuis TradingView, utilisez un pont comme PickMyTrade afin que la santé de la connexion, le rythme d'envoi et la gestion des jetons soient pris en charge pour vous, au lieu de maintenir vous-même un socket brut.
Ce guide est fourni à des fins exclusivement éducatives et informatives et ne constitue ni un conseil financier, ni un conseil en investissement, ni un conseil de trading. Le trading de contrats à terme et d'autres produits à effet de levier comporte un risque de perte important et ne convient pas à tous les investisseurs. PickMyTrade est une plateforme d'automatisation tierce indépendante et n'est ni affiliée à Tradovate, Inc., ni approuvée ou parrainée par cette dernière. « Tradovate » ainsi que tous les noms, logos et marques associés sont la propriété de leurs détenteurs respectifs. Les fonctionnalités et les étapes de la plateforme évoluent avec le temps ; vérifiez donc toujours la procédure en vigueur dans la plateforme et la documentation officielles de Tradovate avant d'agir.