[long polling] Krótkie pytanie Opcje

[markonix]

Powoli zaczynam zapoznawać się z tą technologią bo dużymi krokami zbliża się do mnie konieczność zbudowania komunikatora/czatu o dużej przepustowości.

Zastanawia mnie jednak jedno.
Jak już dobrze zrozumiałem to ta technologia polega na tym, że przeglądarka wysyła żądanie pod podaną stronę (php) i oczekuje na odpowiedź.
Wszystko jest tu dla mnie jasne, zamiast co 3 sekund wysyłać Request HTTP to wysyła go raz i czeka na odpowiedź.

Ale zastanawia mnie co ma się dziać w tym momencie w skrypcie PHP, który np. odpytuje o nowe wiadomości?
Czy tutaj będzie pętla, która co sekundę (sleep) odpytuje bazę o nowe wiadomości?
Jeśli tak to gdzie tu korzyść oprócz zmniejszonej liczby Requestów, które chyba nie są takim obciążaniem jak odpytywanie bazy danych co X sekund?

Ten post edytował markonix 8.10.2012, 20:13:44

[Crozin]

@markonix: Obecnie ceny VPS-ów są na tyle niskie, że spokojnie można z nich korzystać przy średnich czy nawet małych stronach/aplikacjach.

[markonix]

@markonix: Obecnie ceny VPS-ów są na tyle niskie, że spokojnie można z nich korzystać przy średnich czy nawet małych stronach/aplikacjach.

Odnosisz się do tej przenośności? Oj skrypt z koniecznością instalowania na serwerze oprogramowania nie sprzedałby się na Allegro. Na moje oko to 90% stron postawionych jest na hostingach (w tym darmowych) (IMG:style_emoticons/default/wink.gif) Ale to akurat tak tylko na marginesie skomentowałem. Wiadomo, coś za COŚ.


@redeemer powiem Ci, że niezłą zagadkę zrobiłeś z tym przenoszeniem "serwera" pomiędzy zakładkami.
Jedyne co mi przychodzi na myśl to brak odpowiedzi z zakładki serwerowej przez X czasu to sygnał dla zakładki drugiej, aby ta przejęła role serwera.

[redeemer]

@redeemer powiem Ci, że niezłą zagadkę zrobiłeś z tym przenoszeniem "serwera" pomiędzy zakładkami.
Jedyne co mi przychodzi na myśl to brak odpowiedzi z zakładki serwerowej przez X czasu to sygnał dla zakładki drugiej, aby ta przejęła role serwera.

Long polling ma to do siebie, że połączenie może wisieć nawet przez 30 sekund. Lepszym rozwiązaniem będzie dodatkowa funkcja wywoływana z pewnym interwałem czasowym, która co parę sekund będzie odświeżała jakąś zmienną typu timestamp w magazynie lokalnym w "głównej" instancji. Inne instancje będą monitorować wartość tej zmiennej i jeżeli jakiś warunek nie będzie spełniony przejmą jego rolę. Tu z kolei pojawia się problem konkurencyjności, bo js nie jest językiem wielowątkowym i nie możemy określić sekcji krytycznej (brak mutexów), w związku z czym teoretycznie podczas zamknięcia głównej instancji jej role może przejąć w tym czasie wiele innych zakładek, które działały wcześniej w tzw. trybie mirror.

Zwykle w serwerach XMPP można włączyć opcję (lub ją sobie dopisać), aby "multisesje" nie były aktywne, w tym wypadku jeżeli wiele instancji tego samego klienta będzie podłączonych do serwera, wszystkie poza jedną dostaną od serwera stosowną wiadomość disconnect, która po obsłużeniu po stronie klienta spowoduje, aby instancja przeszła w tryb "mirror", czyli bez połączenia do serwera.

Nam jakiś czas temu udało się zbudować taką aplikację zintegrowaną z serwisem społecznościowym, gdzie dodatkowo są też reguły, dotyczące komu kto może wysyłać wiadomości. Użyliśmy ejabberd (na początku był to openfire), strophejs (z modyfikacjami), oraz http://www.jstorage.info/. Niestety branch nigdy nie został włączony do gałęzi production, a szkoda.

Jako lekturę mogę polecić, co prawda już nie pierwszej świeżości (2010 rok), ksiażkę autora biblioteki strophejs Professional XMPP Programming with JavaScript and jQuery