Quali sono i limiti di Websocket?

Cos’è Websocket, in termini semplici?

Websocket è un protocollo di comunicazione che mantiene aperta una connessione tra due sistemi. Dopo la configurazione iniziale, entrambe le parti possono inviarsi messaggi senza dover creare ripetutamente nuove richieste. Nella pratica, questo può essere utilizzato per trasmettere aggiornamenti (ad esempio, quotazioni o eventi di mercato) da un fornitore di dati di mercato o da una piattaforma a un client.

È utile distinguere due concetti:

• La meccanica del protocollo: come i messaggi vengono inviati e ricevuti attraverso una connessione aperta.
• L’utilità per il mercato: se i messaggi ricevuti sono tempestivi, completi e coerenti con quanto necessario per una specifica applicazione.

Il limite principale è che Websocket si occupa solo di come trasportare i messaggi, non di verificare se questi rappresentino informazioni stabili, in tempo reale o valide nel lungo termine.

Come funziona Websocket e quali assunzioni possono rivelarsi errate?

Con Websocket, i messaggi viaggiano attraverso un canale persistente. In un tipico scenario di streaming, un client si iscrive a determinati dati (per simbolo, strumento o argomento), e il server invia aggiornamenti man mano che si verificano.

Le assunzioni chiave dietro l’aspettativa che “funzioni bene” includono:

• La connessione rimane sana abbastanza a lungo perché l’applicazione funzioni.
• I messaggi arrivano in un ordine e con una frequenza utilizzabili per la logica applicativa.
• Il server effettivamente pubblica gli aggiornamenti come ci si aspetta (per la sottoscrizione scelta e nel momento dato).
• Il client è in grado di elaborare i messaggi abbastanza velocemente da stare al passo.

Quando una di queste assunzioni fallisce, si possono verificare conseguenze come aggiornamenti mancanti, ritardi aumentati, accumulo di dati o tentativi ripetuti di riconnessione.

Esempi di modalità di errore osservabili (senza presupporre comportamento in tempo reale)

Anche senza presupporre dati di mercato in tempo reale, è comunque possibile valutare le modalità di errore dal punto di vista della progettazione del sistema:

1. Lacune di riconnessione: se la connessione si interrompe, il client potrebbe riconnettersi in ritardo. Durante questo intervallo, alcuni aggiornamenti potrebbero essere persi.
2. Backpressure e buffering: se l’elaborazione dei messaggi o la capacità della rete è più lenta della frequenza di arrivo degli aggiornamenti, i messaggi possono accumularsi, aumentando la latenza.
3. Necessità di ordinamento e deduplicazione: spesso i sistemi devono gestire duplicati (tentativi dopo riconnessione) e messaggi arrivati fuori ordine a seguito di riconnessioni.

Un errore comune è considerare la consegna tramite un socket persistente come sinonimo di tempestività o completezza perfette. Websocket può ridurre il sovraccarico comunicativo, ma non elimina la necessità di gestire lacune, duplicati e allineamento temporale.

Limitazioni e rischi: quando Websocket è meno utile

I limiti di Websocket sono più evidenti quando interagiscono con condizioni esterne variabili:

• Volatilità di rete e infrastruttura: latenza, perdita di pacchetti o connettività intermittente possono comunque influenzare quando e come arrivano i messaggi.
• Cambiamenti nel comportamento del fornitore/server: la frequenza degli aggiornamenti, le sottoscrizioni disponibili o le politiche di limitazione possono variare a seconda del fornitore e delle condizioni.
• Divergenza tra tempo dei dati e tempo di esecuzione: anche se si ricevono dati rapidamente, le azioni successive (come calcoli, gestione ordini o pianificazione del sistema) potrebbero comunque subire ritardi.
• Costi e complessità operativa: le connessioni persistenti, le strategie di riconnessione e il monitoraggio aggiungono complessità; maggiore è la complessità, maggiore è la probabilità di errori in casi limite.
• Incertezza sulla “precisione in tempo reale”: le relazioni storiche tra il timing dei messaggi e i risultati non garantiscono che lo stesso rapporto si manterrà in futuro.

Poiché questi fattori variano tra sistemi e giurisdizioni, Websocket dovrebbe essere considerato un semplice meccanismo di trasporto, e ciò che si riceve va sempre verificato nelle proprie condizioni operative effettive.

Come verificare autonomamente i limiti di Websocket

Per verificare i limiti senza fare affidamento su promesse, definire controlli misurabili per la propria configurazione. Ad esempio:

• Registrare gli eventi di connessione/disconnessione, e misurare quanto durano le lacune di riconnessione.
• Misurare il ritardo end-to-end del messaggio, dal momento della ricezione a quando l’applicazione lo utilizza.
• Verificare se il sistema gestisce correttamente duplicati e messaggi mancanti dopo una riconnessione.
• Valutare se il volume di messaggi durante periodi di alta attività causa accumulo nell’elaborazione.

Se i requisiti includono tempestività o completezza rigorose, considerare se la progettazione prevede monitoraggio, riconciliazione e gestione robusta dell’incertezza. In generale, il limite di Websocket non è il protocollo stesso, ma il modo in cui le assunzioni su consegna, tempistica e qualità dei dati vengono validate (o meno) nell’ambiente reale.