Vorrei solo aggiungere una prospettiva più elevata a ciò che è stato detto, e cioè che SSE è modello di sottoscrizione di pubblicazione in contrapposizione a polling costante in caso di AJAX.
In genere, entrambi i modi (polling e publish-subscribe) stanno cercando di risolvere il problema su come mantenere uno stato aggiornato sul client.
1) Polling model
È semplice. Il client (browser) prima ottiene uno stato iniziale (pagina) e per l'aggiornamento, ha bisogno di richiedere periodicamente lo stato (pagina o sua parte) ed elaborare il risultato nello stato corrente (aggiornare l'intera pagina o renderlo in modo inteligente nel suo stato parte nel caso di AJAX).
Naturalmente, uno svantaggio è che se non accade niente con lo stato del server, le risorse (CPU, rete, ...) vengono utilizzate inutilmente. Un altro è che anche se lo stato cambia i client lo ottiene solo al successivo periodo di polling, non al più presto. Spesso è necessario valutare un buon compromesso temporale tra le due cose.
Un altro esempio di polling è uno spinwait nella filettatura.
2) publish-subscribe modello
Funziona come segue:
- (client prime richieste e mostra un certo stato iniziale)
- cliente sottoscrive il server (invia una richiesta, possibilmente con un certo contesto come sorgente di eventi)
- server contrassegna il riferimento al client ad alcuni dei suoi repository di riferimento client
- in caso di un aggiornamento dello stato, se rver invia una notifica al client in base al riferimento al client che detiene; vale a dire che non è una risposta a una richiesta, ma un messaggio avviata dal server
- buoni clienti annullare l'iscrizione quando non sono più interessati alle notifiche
Questo è SSE, o all'interno di infilare un evento waitable, come un altro esempio. Un inconveniente naturale, come affermato, è che il server deve conoscere tutti i suoi client sottoscritti che, a seconda dell'implementazione, possono essere un problema.