Passer au contenu principal

​
Qu’est-ce qu’une déconnexion ?

Établir une connexion aux API de streaming implique d’émettre une requête HTTPS de très longue durée et d’analyser la réponse au fil de l’eau. Lors de la connexion à l’endpoint de flux filtré, vous devez émettre une requête HTTPS et consommer le stream résultant aussi longtemps que possible. Nos serveurs maintiendront la connexion ouverte indéfiniment, sauf en cas d’erreur côté serveur, de latence excessive côté client, de problèmes réseau, de maintenance serveur planifiée ou de connexions en double. Avec les connexions aux endpoints de streaming, il est probable — et il faut s’y attendre — que des déconnexions se produisent et qu’une logique de reconnexion soit mise en place.  

​
Pourquoi une connexion de streaming peut être interrompue

Votre stream peut se déconnecter pour plusieurs raisons. Examinez le message d’erreur renvoyé par le stream pour comprendre la cause de l’échec. Les raisons possibles de déconnexion sont les suivantes :
  • Une erreur d’authentification (par exemple, un jeton incorrect ou une méthode d’authentification inappropriée).
  • Un serveur de streaming est redémarré côté X. Cela est généralement lié à un déploiement de code et doit être anticipé et pris en compte dans la conception.
  • Votre client ne parvient pas à suivre le volume de Posts livré par le stream ou lit les data trop lentement. Chaque connexion de streaming s’appuie sur une file de messages à envoyer au client. Si cette file devient trop grande au fil du temps, la connexion sera fermée.
  • Votre compte a dépassé votre quota quotidien/mensuel de Posts.
  • Vous avez trop de connexions redondantes actives.
  • Un client cesse soudainement de lire les data. Si le débit de Posts lus depuis le stream chute brusquement, la connexion sera fermée.
  • D’éventuels problèmes réseau entre le serveur et le client
  • Un problème temporaire côté serveur, une maintenance planifiée ou des mises à jour. (Consultez la page de statut)  

​
Les erreurs de déconnexion courantes comprennent :

	"errors": [{
		"title": "operational-disconnect",
		"disconnect_type": "UpstreamOperationalDisconnect",
		"detail": "Ce stream a été déconnecté en amont pour des raisons opérationnelles.",
		"type": "https://api.x.com/2/problems/operational-disconnect"
	}]
}

{
	"title": "ConnectionException",
	"detail": "Ce stream a actuellement atteint la limite maximale de connexions autorisées.",
	"connection_issue": "TooManyConnections",
	"type": "https://api.x.com/2/problems/streaming-connection"
}

​
Anticiper les déconnexions et se reconnecter

Lors du streaming de Posts, l’objectif est de rester connecté aussi longtemps que possible, en sachant que des déconnexions peuvent survenir. L’endpoint envoie un signal de maintien en vie toutes les 20 secondes (il se présente comme un caractère de saut de ligne). Utilisez ce signal pour détecter une éventuelle déconnexion.
  1. Votre code doit détecter lorsque le nouveau contenu et le heartbeat cessent d’arriver.
  2. Le cas échéant, votre code doit déclencher une logique de reconnexion. Certains clients et langages permettent de spécifier un délai d’expiration de lecture, que vous pouvez définir à 20 secondes.
  3. Votre service doit détecter ces déconnexions et se reconnecter dès que possible.
Une fois une connexion établie interrompue, tentez de vous reconnecter immédiatement. Si la reconnexion échoue, ralentissez vos tentatives en fonction du type d’erreur rencontrée :
  • Appliquez un retrait linéaire en cas d’erreurs réseau au niveau TCP/IP. Ces problèmes sont généralement temporaires et se résolvent rapidement. Augmentez le délai entre les reconnexions de 250 ms à chaque tentative, jusqu’à 16 secondes.
  • Appliquez un retrait exponentiel en cas d’erreurs HTTP pour lesquelles une reconnexion est appropriée. Commencez par une attente de 5 secondes, en doublant à chaque tentative, jusqu’à 320 secondes.
  • Appliquez un retrait exponentiel en cas d’erreurs HTTP 429 (Rate limit exceeded). Commencez par une attente de 1 minute et doublez à chaque tentative. Notez que chaque HTTP 429 reçu augmente le temps d’attente avant que la limite de taux ne cesse de s’appliquer à votre compte.  

​
Récupération des données perdues

En cas de déconnexion, plusieurs stratégies permettent de s’assurer que vous recevrez toutes les données que vous avez pu manquer. Nous avons documenté les principales étapes à suivre pour récupérer les données manquées dans notre guide d’intégration consacré à la récupération des données.   

​
Limites de taux et utilisation

Pour vérifier les limites de connexion, la réponse renverra trois en-têtes. Cela est utile pour comprendre combien de fois vous pouvez utiliser l’endpoint de règles et combien de tentatives de reconnexion sont autorisées pour l’endpoint de streaming.
  • x-rate-limit-limit indique le nombre de requêtes allouées que votre client est autorisé à effectuer durant la fenêtre de 15 minutes.
  • x-rate-limit-remaining indique le nombre de requêtes effectuées jusqu’à présent dans la fenêtre de 15 minutes.
  • x-rate-limit-reset est un horodatage UNIX indiquant le moment où la fenêtre de 15 minutes redémarrera, réinitialisant x-rate-limit-remaining à 0.
L’endpoint de stream de filtrage ne remonte actuellement pas de données d’utilisation. Pour vérifier combien de Posts ont été livrés, votre code peut implémenter une logique de comptage, afin que la consommation puisse être mesurée et mise en pause si nécessaire. Le code côté client du stream insère simplement les Posts entrants dans une file d’attente premier entré, premier sorti (FIFO), ou une structure mémoire similaire ; un processus/thread distinct doit consommer les Posts depuis cette file pour analyser et préparer le contenu en vue de son stockage. Avec cette conception, vous pouvez implémenter un service qui met l’échelle efficacement si les volumes de Posts entrants varient fortement. Conceptuellement, vous pouvez l’imaginer comme le téléchargement d’un fichier infiniment long via HTTP.

​
Bonnes pratiques de reconnexion

Tester les stratégies de backoff Une bonne façon de tester une implémentation de backoff consiste à utiliser des informations d’authentification invalides et à observer les tentatives de reconnexion. Une implémentation robuste ne devrait recevoir aucune réponse 429. Émettre des alertes en cas de reconnexions multiples Si un client atteint le seuil supérieur de l’intervalle entre les reconnexions, il doit vous envoyer des notifications afin que vous puissiez prioriser les problèmes affectant votre connexion. Gérer les changements DNS Vérifiez que votre processus client respecte le TTL (Time To Live) du DNS. Certaines piles mettent en cache une adresse résolue pendant toute la durée du processus et ne tiennent pas compte des changements DNS dans le TTL prescrit. Un tel cache agressif entraînera des interruptions de service côté client lorsque X répartit la charge entre des adresses IP. User-Agent Assurez-vous que votre en-tête HTTP User-Agent inclut la version du client. Cela sera essentiel pour diagnostiquer les problèmes côté X. Si votre environnement empêche la définition du champ User-Agent, définissez un en-tête x-user-agent.
⌘I