WebSocket & PHP - opinie i ocena - czy warto? Opcje

[modern-web]

Jak w temacie, chciałbym dowiedzieć się co sądzicie o protokole WebSocket i jego zastosowaniach w połączeniu z PHP. Może macie jakieś doświadczenia z tą technologią i opinię, którą chcielibyście się podzielić?

Pozdrawiam!

Ten post edytował modern-web 26.07.2012, 00:45:51

[d3ut3r]

Podstawową zaletą Moim zdaniem jest dwukierunkowość połączenia, niesie to ze sobą zyski w postaci choćby wydajności aplikacji. Dotychczas komunikacja aplikacji webowej z serwerem, była jednostronna czyli przeglądarka pytała serwer odpowiadał. AJAX był sporą rewolucją ale nadal mieliśmy do czynienia z jednostronną komunikacją i aby np napisać chat musieliśmy wysyłać co określony czas nowe zapytanie aby zaktualizować dane.

[!*!]

Dobra rzecz, przydatne w czymś tak prostym jak chat i rozbudowanych grach.

[erix]

Może macie jakieś doświadczenia z tą technologią i opinię, którą chcielibyście się podzielić?

Głównym problemem jest to, że ta technologia, to - oficjalnie - szkic. Przypomnę tylko, że przez dobre kilka miesięcy była zablokowana w niektórych przeglądarkach ze względów bezpieczeństwa.

Bez fallbacków na tradycyjne rozwiązania nie ma to sensu, niestety...

[thek]

Ja także bym się tylko póki co zapoznał. W związku z problemami bezpieczeństwa jest domyślnie wyłączana i tym samym jej użycie jest ograniczone. Co do fallbacku to da się...
http://code.google.com/p/jquery-graceful-websocket/

[CuteOne]

Zastanawialiście się kiedyś do czego można użyć WebSockets? Pomijając czaty i gierki, które można tworzyć w javie/flashu to tak naprawdę nie ma większego zastosowania - a jeżeli ma to ja go do dzisiaj nie spotkałem. Dodatkowym minusem są koszty - nie wielki odsetek firm stać(lub jest to dla nich opłacalne) na utrzymanie dedyka a bez niego nie ma co marzyć o własnym WS (IMG:style_emoticons/default/smile.gif)

ps. próbowałem odpalić serwer pod WS na wirtualce to 3h później dostałem upomnienie od admina - taka mała adnotacja dla tych co chcieli by stawiać serwery na wirtualach

Ten post edytował CuteOne 27.07.2012, 06:48:10

[vokiel]

Jeśli mamy 2 skrypty robiące to samo. Jeden na socket'ach drugi odpytuje serwer co 5 sekund, to według mnie, dla serwera lepszy jest socket. Jeśli socketem zabijasz serwer, to jeszcze bardziej zabijesz go ciągłym odpytywaniem. Przewaga socketa rośnie wraz z ilością korzystających na raz klientów, maleje wraz z czestotliwością wiadomości.

[redeemer]

Jeśli mamy 2 skrypty robiące to samo. Jeden na socket'ach drugi odpytuje serwer co 5 sekund, to według mnie, dla serwera lepszy jest socket. Jeśli socketem zabijasz serwer, to jeszcze bardziej zabijesz go ciągłym odpytywaniem. Przewaga socketa rośnie wraz z ilością korzystających na raz klientów, maleje wraz z czestotliwością wiadomości.

Jeszcze jedną alternatywą jest Ajax Push, gdzie połączenie "wisi" i czeka na event od serwera, a nie wysyłany jest request co jakiś interwał.

[hind]

@redeemer: tak zwany long polling

[CuteOne]

@vokiel: i wracamy do mojego pytania - czy widziałeś coś innego(sensownego) niż gierki lub czaty, które stoją na WS? To mówi samo za siebie... jeden wielki niewypał

[erix]

Widzieć nie zobaczysz, bo ta technologia, to dopiero szkic...

[CuteOne]

Erix rozumiem naprawdę ale sporo czasu już upłynęło od momentu pojawienia się tej rewelacji - pamiętam jak pierwszy raz przeczytałem o połączeniu WS z node.js jako następcach PHP i ajaxa. Wyszło jak wyszło.

Teraz takie pytanie - która firma zainwestuje kasę w WS gdy ma tańszą alternatywę w postaci AJAXA (trzeba do tego dodać jQuery - każdy go zna = tańsza siła robocza)?

[erix]

Erix rozumiem naprawdę ale sporo czasu już upłynęło od momentu pojawienia się tej rewelacji - pamiętam jak pierwszy raz przeczytałem o połączeniu WS z node.js jako następcach PHP i ajaxa. Wyszło jak wyszło.

A W3C nadal to trzyma w statusie szkicu, dziury bezpieczeństwa też w tym znajdują, producenci włączają/implementują obsługę kiedy im się spodoba (co jest wypadkową działań W3C).

Teraz takie pytanie - która firma zainwestuje kasę w WS gdy ma tańszą alternatywę w postaci AJAXA (trzeba do tego dodać jQuery - każdy go zna = tańsza siła robocza)?

Tu nie chodzi o kasę, tylko o rentowność. Wykorzystanie WS nie jest takie trudne; gorzej z tym, że można kasę utopić, gdy się okaże, że znaleźli jakiegoś kolejnego babola w technologii i znowu wyłączą jej obsługę w popularnych przeglądarkach.

[!*!]

Tu nie chodzi o kasę, tylko o rentowność. Wykorzystanie WS nie jest takie trudne; gorzej z tym, że można kasę utopić, gdy się okaże, że znaleźli jakiegoś kolejnego babola w technologii i znowu wyłączą jej obsługę w popularnych przeglądarkach.

Co nie zmienia faktu że sam WS jest świetny (IMG:style_emoticons/default/wink.gif) a projekty pokroju gier, nie są za 2k zł, więc raczej powstaje w nich kilka rozwiązań.

hind - dzięki za przypomnienie nazwy (long polling).

[hind]

ja widzę przyszłość z WS w aplikacjach webowych i pubsub, kiedy chcemy mieć reakcję natychmiastową. Budowanie interfejsu w HTML w przeglądarce a przez WS transportować wszystkie eventy do i z aplikacji uruchomionej na serwerze. Od model MVC

[vokiel]

Zastosowań można znaleźć wiele, zwłaszcza biznesowych jak chociażby wspólna praca nad jednym dokumentem.
Ze względu na zawirowania ze standaryzacją i implementacją w przeglądarkach jedynym rozwiązaniem jest zamrożenie wybranej wersji przeglądarki i stworzenie aplikacji do niej dedykowanej. Taki intranetowy system, w dużej korporacji, gdzie można wymusić jedyną właściwą przeglądarkę, w jednej wersji u wszystkich. Tak jak kiedyś było robione z IE i dedykowanymi kontrolkami ActiveX.

Tylko tak jak piszecie, kto zechce wchodzić w coś takiego, z góry narzucać sobie takie ograniczenia. Dodatkowy RAM do serwera wyjdzie o wiele taniej i mniej problematycznie.