Zdarzenia wysłane przez serwer vs ankiety

Dodałbym tylko wyższą perspektywę do tego, co zostało powiedziane, a mianowicie, że SSE jest modelem publish-subscribe w przeciwieństwie do ciągłego sondowania w przypadku AJAX.

Ogólnie rzecz biorąc, oba sposoby (ankieta i publish-subscribe) próbują rozwiązać problem, jak utrzymać aktualny stan na kliencie.

1) Wzór ankiety

To proste. Klient (przeglądarka) najpierw otrzymuje stan początkowy (strona) i aby go zaktualizować, musi okresowo żądać stanu (strona lub jej część) i przetworzyć wynik do bieżącego stanu (odświeżyć całą stronę lub renderować ją inteligentnie do jej części w przypadku AJAX).

Oczywiście jedną z wad jest to, że jeśli nic się nie stanie z serwerem stan zasobów (CPU, sieci, ...) są wykorzystywane niepotrzebnie. Innym jest to, że nawet jeśli stan się zmieni, klienci otrzymują go dopiero w następnym okresie ankiety, a nie JAK NAJSZYBCIEJ. Często trzeba ocenić dobry kompromis czasowy między tymi dwoma rzeczami.

Kolejny przykład sondażu jest spinwait w gwintowaniu.

2) Publikuj-Subskrybuj model

To działa w następujący sposób:

• (klient najpierw żąda i pokazuje jakiÅ› stan poczÄ…tkowy)
Klient subskrybuje serwer (wysyła jedno żądanie, ewentualnie z jakimś kontekstem, np. źródłem zdarzenia) Serwer oznacza odniesienie do Klienta do jakiegoś repozytorium referencji klienta.]}
• W przypadku aktualizacji stanu, serwer wysyÅ‚a powiadomienie do klienta na podstawie odniesienia do klienta nie jest to odpowiedź na żądanie, ale wiadomość zainicjowana przez Serwer
Dobry klient rezygnuje z subskrypcji, gdy nie jest już zainteresowany powiadomieniami]}

Jest to SSE, lub w wątku zdarzenia waitable, jako inny przykład. Naturalną wadą, jak wspomniano, jest to, że serwer musi wiedzieć o wszystkich swoich subskrybowanych klientach, co w zależności od implementacji może być problemem.