Dovrebbe esserci un solo oggetto EventSource per app?

Question

Quando si utilizza Server-Sent Events nel caso in cui il client stabilisca più connessioni per ricevere eventi diversi a cui è interessato, o dovrebbe esserci una singola connessione e il client indica che cosa è interessato tramite un canale separato? IMO quest'ultimo sembra più preferibile anche se ad alcuni potrebbe rendere il codice client più complesso. Le specifiche supportano eventi denominati (eventi relativi a un particolare argomento), che a mio avviso suggeriscono che una connessione Eventi-Server inviati debba essere utilizzata come singolo canale per tutti gli eventi.

Il codice seguente illustra il primo scenario in cui vengono avviate a connessioni multiple Event Server-Sent:

var EventSource eventSource1 = new EventSource("events/topic1"); 
eventSource1.addEventListener('topic1', topic1Listener, false); 

var EventSource eventSource2 = new EventSource("events/topic2"); 
eventSource2.addEventListener('topic2', topic2Listener, false); 

eventSource1 riceverebbe eventi "TOPIC1" e eventSource2 riceverebbe eventi "TOPIC2". Anche se questo è piuttosto semplice, è anche abbastanza inefficiente con un pensile GET che si verificano per ogni argomento che ti interessa

L'alternativa è qualcosa di simile al seguente:.

var EventSource eventSource3 = new EventSource("/events?id=1234") 
eventSource3.addEventListener('topic3', topic3Listener, false); 
eventSource3.addEventListener('topic4', topic4Listener, false); 

var subscription = new XMLHttpRequest(); 
subscription.open("PUT", "/events/topic3?id=1234", true); 
subscription.send(); 

In questo esempio un singolo EventSource farebbe l'esistenza e l'interesse in un particolare evento sarebbero specificati da una richiesta separata con la connessione Event-Server-Sent e la registrazione essendo correlata dal parametro id. topic3Listener riceverebbe eventi "topic3" e topic4Listener non lo farebbe. Pur richiedendo un numero leggermente maggiore di codice, il vantaggio è che viene effettuata una sola connessione, ma gli eventi possono ancora essere identificati e gestiti in modo diverso.

Ci sono alcuni esempi sul web che mostrano l'uso di eventi con nome, ma sembra che i nomi degli eventi (o argomenti) siano noti in anticipo quindi non è necessario che un client registri interessi con il server (example). Anche se devo ancora vedere un esempio che mostra più oggetti EventSource, non ho visto nemmeno un esempio che mostra un client che utilizza una richiesta separata per registrare l'interesse in un particolare argomento, come sto facendo sopra. La mia interpretazione delle specifiche mi porta a credere che indicare un interesse per un determinato argomento (o nome di un evento) sia interamente a carico dello sviluppatore e che possa essere fatto staticamente con il cliente conoscendo i nomi degli eventi che sta per ricevere o in modo dinamico con il client che avvisa il server che è interessato a ricevere eventi particolari.

Sarei molto interessato ad ascoltare i pensieri di altre persone sull'argomento. NB: Di solito sono un dev di Java quindi per favore perdonami il mio mediocre codice JS .. :)

Answer 1

Mi raccomando, IMHO, che tu abbia un oggetto EventSource per servizio di fornitura SSE, e poi emetti i messaggi usando tipi diversi .

In definitiva, tuttavia, dipende da quanto siano simili i tipi di messaggi. Ad esempio, se hai 5 diversi tipi di messaggi relativi agli utenti, disponi di un utente EventSource e differenziati con i tipi di evento.

Se si dispone di un tipo di evento sugli utenti, e un altro sui panini, direi di tenerli in diversi servizi, e quindi EventSource s.

È una buona idea pensare di suddividere EventSources nello stesso modo in cui si farebbe un servizio rilassante. Se non si ottengono due cose dallo stesso servizio con AJAX, probabilmente non si dovrebbero ottenere dallo stesso EventSource.

Answer 2

In risposta all'interpretazione standard del browser vago e permissivo *, i fornitori di browser hanno applicato in modo incoerente restrizioni al numero di connessioni permanenti consentite a un singolo dominio/porta.Poiché ogni ricevitore di eventi in un contesto asincrono assume una singola allocazione di connessione permanente per tutto il tempo in cui il ricevitore è aperto, è fondamentale che il numero degli ascoltatori di EventSource sia rigorosamente limitato per evitare di superare i limiti specifici del produttore. In pratica, ciò limita a circa 6 coppie di contesto EventSource/async per applicazione. La degradazione è aggraziata (ad esempio richieste di connessione EventSource aggiuntive attenderanno solo fino a quando uno slot è disponibile), ma tieni presente che devono essere disponibili connessioni per recuperare risorse di pagina, rispondere a XHR, ecc.

* Il W3C ha emesso standard con rispetto alle connessioni persistenti che contengono la lingua "... DOVREBBE limitare il numero di connessioni simultanee ..." Questo linguaggio indica che lo standard non è obbligatorio, quindi la conformità del fornitore è variabile. http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.4