[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

[markonix]

Jeszcze wracając do "prostego" polling.
Jaki czas powinno mieć oczekiwanie na odpowiedź?
Początkowo wydawało mi się czym dłużej tym lepiej bo w końcu chodzi o zmniejszenie liczby requestów.
No ale gdy stworzyłem testowy skrypt to po 45 sekundach otrzymałem error 500.

No i teraz pytanie co z tym zrobić?
- Przechwycić błąd

[JAVASCRIPT] pobierz, plaintext 
error : function(XMLHttpRequest, textstatus, error) { 
comet();
}
[JAVASCRIPT] pobierz, plaintext 

i od nowa oczekiwanie?
- Starać się jak najbardziej zwiększyć czas wykonywania skryptu (albo najlepiej no-limit)?

Te pierwsze wydaje mi się bardziej bezpiecznie ale przykładowo przymierzam się do poprawek w obecnych skryptach gdzie np. teraz wartości odświeżane są co 15 sekund. Wprowadzając omawianą technikę to będzie oszczędność dość mizerna (1 zamiast 3), a gdyby execute_time wynosił np. 10 minut to już gdzieś oszczędność na poziomie 40 requestów i jakoś bardziej działa to na wyobraźnie i motywuje do przeróbek w obecnych skryptach.

Ten post edytował markonix 10.10.2012, 11:58:32

[redeemer]

http://tools.ietf.org/html/rfc6202#page-15 5.5 Timeouts (ale cały dokument jest warty uwagi)


Co ciekawe w drafcie http://tools.ietf.org/html/draft-loreto-ht...onal-07#page-15 jest to bardziej rozwinięte i możemy tam przeczytać dodatkowo:

Several experiments have shown success with timeouts as high as 120
seconds, but generally 30 seconds is a safer value. Therefore
vendors of network equipment wishing to be compatible with the HTTP
long polling mechanism are advised to implement a timeout