Vai al contenuto principale

​
Che cos’è una disconnessione?

Stabilire una connessione alle API di streaming significa effettuare una richiesta HTTPS di lunga durata e analizzare la risposta in modo incrementale. Quando ci si connette all’endpoint filtered stream, è consigliabile inviare una richiesta HTTPS e consumare lo stream risultante per tutto il tempo possibile. I nostri server manterranno la connessione aperta a tempo indeterminato, salvo errori lato server, eccessivo ritardo lato client, problemi di rete, manutenzione ordinaria del server o accessi duplicati. Con le connessioni agli endpoint di streaming, è probabile — e ci si dovrebbe aspettare — che si verifichino disconnessioni e che venga implementata la logica di riconnessione.  

​
Perché una connessione in streaming può disconnettersi

Lo stream può disconnettersi per vari motivi. Esamina il messaggio di errore restituito dallo stream per comprenderne la causa. Possibili cause di disconnessione:
  • Un errore di autenticazione (ad esempio un token errato o l’uso di un metodo di autenticazione non corretto).
  • Un server di streaming viene riavviato lato X. Di solito è correlato a un deploy del codice ed è un evento prevedibile da considerare in fase di progettazione.
  • Il client non riesce a tenere il passo con il volume di Post che lo stream sta recapitando oppure legge i data troppo lentamente. Ogni connessione di streaming è supportata da una coda di messaggi destinati al client. Se questa coda cresce troppo nel tempo, la connessione verrà chiusa.
  • L’account ha superato la quota giornaliera/mensile di Post.
  • Sono presenti troppe connessioni ridondanti attive.
  • Un client smette improvvisamente di leggere i data. Se il ritmo di Post letti dallo stream cala bruscamente, la connessione verrà chiusa.
  • Possibili problemi di rete tra server e client.
  • Un problema temporaneo lato server, manutenzione o aggiornamenti programmati. (Consulta la status page)  

​
Tra gli errori di disconnessione più comuni figurano:

	"errors": [{
		"title": "operational-disconnect",
		"disconnect_type": "UpstreamOperationalDisconnect",
		"detail": "Questo stream è stato disconnesso a monte per motivi operativi.",
		"type": "https://api.x.com/2/problems/operational-disconnect"
	}]
}

{
	"title": "ConnectionException",
	"detail": "Questo stream ha attualmente raggiunto il limite massimo di connessioni consentite.",
	"connection_issue": "TooManyConnections",
	"type": "https://api.x.com/2/problems/streaming-connection"
}

​
Prevedere le disconnessioni e riconnettersi

Durante lo stream di Post, l’obiettivo è rimanere connessi il più a lungo possibile, tenendo presente che possono verificarsi disconnessioni. L’endpoint invia un segnale di keep-alive ogni 20 secondi (si presenta come un carattere di nuova riga). Usa questo segnale per rilevare se stai per essere disconnesso.
  1. Il tuo codice dovrebbe rilevare quando smettono di arrivare nuovi contenuti e il segnale di keep-alive.
  2. In tal caso, il tuo codice dovrebbe attivare la logica di riconnessione. Alcuni client e linguaggi permettono di impostare un timeout di lettura, che puoi fissare a 20 secondi.
  3. Il tuo servizio dovrebbe rilevare queste disconnessioni e riconnettersi il prima possibile.
Una volta che una connessione stabilita si interrompe, prova a riconnetterti immediatamente. Se la riconnessione non riesce, riduci la frequenza dei tentativi in base al tipo di errore riscontrato:
  • Esegui un backoff lineare per errori di rete a livello TCP/IP. Questi problemi sono generalmente temporanei e tendono a risolversi rapidamente. Aumenta il ritardo tra le riconnessioni di 250 ms a ogni tentativo, fino a 16 secondi.
  • Esegui un backoff esponenziale per errori HTTP per i quali la riconnessione è appropriata. Inizia con un’attesa di 5 secondi, raddoppiando a ogni tentativo, fino a 320 secondi.
  • Esegui un backoff esponenziale per errori HTTP 429 Rate limit exceeded. Inizia con un’attesa di 1 minuto e raddoppia a ogni tentativo. Nota che ogni HTTP 429 ricevuto aumenta il tempo di attesa necessario finché il limite di velocità non sarà più in vigore per il tuo account.  

​
Recupero dei dati persi

Se si verifica una disconnessione, puoi adottare diverse strategie per assicurarti di ricevere tutti i dati che potresti aver mancato. Abbiamo documentato alcuni passaggi chiave per recuperare i dati mancanti nella nostra guida all’integrazione sul recupero dei dati.   

​
Limiti di velocità e utilizzo

Per verificare i limiti di connessione, la risposta restituirà tre intestazioni. Questo è utile per capire quante volte puoi usare l’endpoint delle regole e quanti tentativi di riconnessione sono consentiti per l’endpoint di streaming.
  • x-rate-limit-limit indica il numero di richieste assegnate che il tuo client può effettuare nella finestra di 15 minuti.
  • x-rate-limit-remaining indica il numero di richieste effettuate finora nella finestra di 15 minuti.
  • x-rate-limit-reset è un timestamp UNIX che indica quando la finestra di 15 minuti verrà riavviata, reimpostando x-rate-limit-remaining a 0.
L’endpoint filter stream al momento non riporta i dati di utilizzo. Per verificare quante Post sono state consegnate, il tuo codice può implementare una logica di misurazione, in modo che il consumo possa essere misurato e messo in pausa se necessario.  Il codice che esegue il lato client dello stream inserisce semplicemente le Post in arrivo in una coda first in, first out (FIFO) o in una struttura di memoria simile; un processo/thread separato dovrebbe prelevare le Post da quella coda per analizzarle e prepararle per l’archiviazione. Con questo design, puoi implementare un servizio che può scalare in modo efficiente nel caso in cui i volumi di Post in arrivo cambino drasticamente. Concettualmente, puoi pensarci come allo scaricamento di un file infinitamente lungo tramite HTTP.

​
Best practice per la riconnessione

Testare le strategie di backoff Un buon modo per testare un’implementazione di backoff è usare credenziali di autorizzazione non valide ed esaminare i tentativi di riconnessione. Una buona implementazione non dovrebbe mai ricevere risposte 429. Generare avvisi per riconnessioni multiple Se un client raggiunge la soglia massima dell’intervallo tra le riconnessioni, dovrebbe inviarti notifiche così da poter eseguire il triage dei problemi che influiscono sulla connessione. Gestire le modifiche DNS Verifica che il processo del tuo client rispetti il TTL (Time To Live) del DNS. Alcuni stack memorizzano nella cache un indirizzo risolto per l’intera durata del processo e non recepiscono le modifiche DNS entro il TTL previsto. Un caching così aggressivo comporterà interruzioni del servizio sul tuo client mentre X distribuisce il carico tra indirizzi IP. User Agent Assicurati che l’header HTTP user-agent includa la versione del client. Questo sarà fondamentale per diagnosticare i problemi dal lato di X. Se il tuo ambiente impedisce l’impostazione del campo user-agent, imposta un header x-user-agent.
⌘I