Ten dział chyba będzie najlepszy na taki temat...

Tak się ostatnio zastanawiałem: czy jest skuteczny, oparty na zdarzeniach, sposób na komunikację serwera z klientami? Obojętnie: język programowania, technologia, skrypt, cokolwiek.

Mam na myśli taką przykładową sytuację: mamy serwis prezentujący jakieś informację aktualizowane na bieżąco, jednak zależne od zdarzeń. Ilość zdobytych punktów w meczu, czas najszybszego okrążenia, pojawienie się nowego konsultanta w serwisie, etc. Cokolwiek, co opiera się na zdarzeniu, a nie na czasie. Teraz, standardowo, każdy klient odpytuje serwer co zadany interwał czasu, czy przypadkiem dana rzecz się nie zmieniła (ajax). Rozwiązanie to przy np 10k użytkowników on-line powoduje sporo zbędnego ruchu i obciążenia. Jeśli dane pojawiają się w całkowicie losowych odstępach ciężko jest nawet ustawić sensowny interwał dla odświeżania. Sensowniej by było, gdyby aplikacje www u klienta "oczekiwały" na sygnał, informację z serwera w momencie aktualizacji danych.

Oczywiście można zrobić taki ajaksowy systemik do aktualizacji, a po stronie serwera dobry cache (nawet statyczny plik), odpowiednie nagłówki, etc. - będzie działać. Jednak ciągle pozostaje te X zbędnych połączeń, które powstają, odpytują serwer dostają wielkie nic (304 Not Modified), zamykają się, czekają określony czas i znów męczą bez potrzeby serwer...

Jedyne co znalazłem, to: Comet, Web Sockets, coś o BEA WebLogic Event Server

Czy jest sensowna metoda na taki sposób komunikacji?

Spotkałem się ze wzorcem, który polegał na wywoływaniu żądania przez ajax do skryptu, który usypiał do czasu w którym nastąpiło coś nowego (lub np. po 30 sekundach). Od razu po "wzbudzeniu" skryptu żądanie się kończyło, dane przesyłane a połączenie nawiązywane na nowo (nowe żądanie).
Takie rozwiązanie na pewno zmniejszyło by ruch pomiędzy serwerem a klientem, nie mam pojęcia jednak czy serwer wyrobiłby przy takiej ilości połączeń i zatrzymanych wątków php. Na pewno przydałaby się jakaś specjalna konfiguracja.
Innych sensowych rozwiązań (działających wszędzie i wykorzystujących protokół HTTP) nie widzę...

Jesli chcesz oprzec calosc na zdarzeniach to juz w tym momencie Twoje podejscie jest zle. Gdy cos sie stanie to serwer powinien informowac o tym klientów wysyłając do nich odpowiedni komunikat. Cos na zasadzie komunikatora internetowego. Klient nie odpytuje serwera co 1ms czy nie ma nowych wiadomosci tylko slucha na okreslonym porcie czy serwer mu czegos nie podeslal

flash + fms

Ładny applet w javie i jedziemy Ja używam takiego rozwiązania dla wielu klientów i sprawdza się idealnie.

Chodziło mi właśnie o to, że teraz stosuję takie rozwiązanie, a chciałbym zmienić. Szukam możliwości zmiany na te, o którym jest wątek.

@seth-kk tak właśnie myślałem, że to raczej w stronę flash'a. Tyle, że Flash Media Server w wersji 3.5 (Interactive) to koszt powyżej 15k.

Totalnie chamskim rozwiazaniem byloby wydzielenie oddzielnej maszyny tylko do "pingowania" na konkretne adresy. Niech pobieraja np. jakis hash i po problemie (w architekturze, ze to klient regularnie odpytuje serwer). Na pewno zmniejsza to ruch na glownym serwerze, ktory nie musi procesowac duzej ilosci zapytan, a moze zajac sie konkretnymi rzeczami.

Kiedy cos zmieni sie powaznie na glownym serwerze wowczas idzie info do tego swoistego proxy (np. zmienia sie hash) i wtedy klient otrzymujac inna odpowiedz niz poprzednia leci do glownego serwera. Tam juz w jakims cache czeka na niego nowa wersja contentu.

To tak na szybko i chamsko, ide po kawe bo zasne.

Moze cie zainteresuje APE Server

Wysyla dane bezposrednio do klienta, nie wymaga zadnych dodatkow po stronie klienta.

www.ape-project.org

To bazuje na Comet, o którym znalazłem gdzieś wzmiankę. Dzięki za link

jest jeszcze red5 ale nim nie mialem okazji sie bawic
jesli mowa o flashu to moznaby tez pokombinowac z P2P

http://twistedmatrix.com/trac/ chociaz napisanie prostej relacji client<->serwer na socketach ktora bedzie operowala na "eventach" nie jest jakims kosmicznym wysilkiem