- 1
- 2
- 3
- Następna »
Maciej
Sikora
Programista
aplikacji
internetowych
Temat: Node.js czy Apache/PHP
Witam, mam niezły orzech od zgryzienia. W mojej aplikacji łącze wielu klientów między sobą. Ciągłe odpytywanie serwera nie jest dobrym rozwiązaniem. Chciałem zaimplementować websockets. Aplikacja po stronie serwera wykonana jest w PHP5, które jak się okazuje nie ma konkretnej biblioteki do obsługi websockets. Jest kilka githubowych projektów, ale są one raczej niszowe. Pytanie brzmi czy implementacja na Apache/PHP może jakkolwiek równać się z promowanym ostatnio node.js?
Tomasz
Elendt
Software Engineer at
Nokia gate5 GmbH
Temat: Node.js czy Apache/PHP
Nie, nie może.
Maciej
Sikora
Programista
aplikacji
internetowych
Temat: Node.js czy Apache/PHP
A może szersze wyjaśnienie.
Tomasz
Elendt
Software Engineer at
Nokia gate5 GmbH
Temat: Node.js czy Apache/PHP
Szersze wyjaśnienie czego? Zadałeś proste, zamknięte pytanie. Dostałeś odpowiedź. Czego oczekujesz?Jeśli oczekujesz szerszej wypowiedzi zadaj odpowiednie pytanie. Pominę kwestię tego, że pytanie powinno kończyć się znakiem zapytania. Czy może mam się domyślać, jakie pytania chodzą Ci po głowie?
1) Czemu łatwiej znaleźć implementacje WebSockets w Node.js niż w Apache + PHP?
Bo takie implementacje (w oparciu o Node.js) zwyczajnie mają większy sens.
2) Co takiego sprawia, że implementacje WebSockets oparte o Node.js są bardziej "sensowne" od tych opartych o Apache + PHP?
Po pierwsze należy zrozumieć na czym polega WebSockets. Cytując specyfikację protokołu:
Protokół WebSockets umożliwia obustronną komunikację pomiędzy klientem (UA) a zdalnym hostem[...]. Celem tej technologii jest dostarczenie mechanizmu aplikacjom opartym o przeglądarkę internetową do obustronnej komunikacji z serwerem, która nie opiera się na otwieraniu wielu połączeń HTTP (np. poprzez użycie XMLHttpRequest lub ramek z "long polling").
Czyli potrzeba "stałego" połączenia pomiędzy klientem a serwerem. Takie połączenia może trwać kilkanaście sekund, minut, a nawet godzin. Różni się to zasadniczo od "standardowego" zapytania HTTP (nie biorąc pod uwagę tzw. "long pollingu"), które można scharakteryzować w uproszeniu w następujący sposób:
KLIENT -> (zapytanie) -> SERWER -> (odpowiedź) -> KLIENT
Zakłada się przy tym, że cały ten proces przebiega stosunkowo szybko. Problem powstaje w momencie, gdy chcemy wydłużyć cały proces. Z czego to wynika? Otóż zarówno PHP (nie ważne, czy działające jako mod_php czy mod_fastcgi) i Apache (nie ważne, czy działa w trybie prefork czy worker) działa w sposób blokujący. IO blokuje cały proces lub wątek. W każdym przypadku jest to kosztowne.
Rozwiązaniem jest nieblokujące IO - takie rozwiązanie przyjęto m.in. w Node.js. Ponadto wykorzystuje ono "model zdarzeniowy" - niemal identyczny do tego znanego ze środowisk przeglądarek internetowych.
Nadal nie wiem, po co potrzebujesz WebSockets, ale nic nie stoi na przeszkodzie (o ile korzystasz z sensownego rozwiązania hostingowego) aby łączyć jedno (Apache + PHP) z drugim (serwer WebSockets oparty np. na Node.js). Jeden proces może komunikować się z drugim na wiele sposobów. Jednym z wielu przykładów jest Google App Engine (działające na zasadzie CGI) z usługą Channels (umożliwiającą trwałe połączenie pomiędzy klientem a serwerem).Tomasz Elendt edytował(a) ten post dnia 25.02.11 o godzinie 01:14
Maciej
Sikora
Programista
aplikacji
internetowych
Temat: Node.js czy Apache/PHP
Dzięki za wyjaśnienie.Websockets potrzebne jest mi do tworzenia gry -> na planszy w jednym momencie porusza się wielu graczy. Myślałem o rozwiązaniu łączonym -> node.js do czatu i szybkich zmian pozycji, Apache/PHP do standardowych wywołań Ajax + ładowanie map.
Kamil Brenk blog.kamilbrenk.pl
Temat: Node.js czy Apache/PHP
Maciej Sikora:To potrzebny Ci WebSockets czy AJAX? Z tego co napisałeś to bardziej potrzebujesz tego pierwszego.
Websockets potrzebne jest mi do tworzenia gry -> na planszy w jednym momencie porusza się wielu graczy. Myślałem o rozwiązaniu łączonym -> node.js do czatu i szybkich zmian pozycji, Apache/PHP do standardowych wywołań Ajax + ładowanie map.
Ps. Lighttpd czy Ngix podobnie jak node.js też są sterowane zdarzeniami i działają na podobnej zasadzie, więc nie ma wielkiej różnicy między tymi serwerami.
Maciej
Sikora
Programista
aplikacji
internetowych
Temat: Node.js czy Apache/PHP
Ajax w tym wypadku musiałby wykonywać się co chwile i sprawdzać wszystkich na planszy -> zmiana ruchu wykonywała by się w jednym momencie u wszystkich.Druga możliwość - każdy gracz jest Workerem, który co chwile wywołuje Ajax ( albo utrzymuje long polling ). Oba rozwiązania powodują ciągłe odpytywanie serwera. Myślałem raczej o połączeniu każdego gracza poprzez Websocket.
Kamil Brenk blog.kamilbrenk.pl
Temat: Node.js czy Apache/PHP
Maciej Sikora:Do cyklicznego odpytywania serwera jest z kolei obiekt EventSource :P
Ajax w tym wypadku musiałby wykonywać się co chwile i sprawdzać wszystkich na planszy -> zmiana ruchu wykonywała by się w jednym momencie u wszystkich.
http://dev.w3.org/html5/eventsource/
http://blog.kamilbrenk.pl/server-sent-events/
Maciej
Sikora
Programista
aplikacji
internetowych
Temat: Node.js czy Apache/PHP
Ciekawe,czyli co - stałe, utrzymujące się połączenie z serwerem z możliwością wielu odpowiedzi w trakcie. Czyli taki lepszy long polling. Nie zmienia to faktu, że na serwerze to będzie wyglądało jak jedna wielka pętla ze sleepem. Czy to będzie lepsze od łączenia klientów Socketami?
Piotr M. programista
Temat: Node.js czy Apache/PHP
Na jakie rozwiązanie się w końcu zdecydowałeś? Czy nie lepiej byłoby do tej wymiany informacji między web-klientami napisać jakiś serwerek w którymś z "normalnych" języków programowania, a nie w PHP?
Maciej
Sikora
Programista
aplikacji
internetowych
Temat: Node.js czy Apache/PHP
Wszystko piszę w js. Serwerek i klienta, powiem szczerze widzę w tym dużą przyszłość i mimo pierwszych problemów z przyzwyczajeniem się do ciągłych callbacków, uważam node.js za świetne rozwiązanie po stronie serwera.Peter M.:
Na jakie rozwiązanie się w końcu zdecydowałeś? Czy nie lepiej byłoby do tej wymiany informacji między web-klientami napisać jakiś serwerek w którymś z "normalnych" języków programowania, a nie w PHP?
Nie chcę zrobić offtopa, ale muszę odpowiedzieć na to - osoby, które krytykują PHP najczęściej nic w nim nie pisały, albo w czymkolwiek mało co pisały. Bo to nie język nie jest "normalny", a programiści, którzy po tygodniu "programowania" myślą, że są świetni.
Piotr M. programista
Temat: Node.js czy Apache/PHP
Spoko ale w tym konkretnym zastosowaniu sam zostawiłeś PHP na rzecz JS?
Maciej
Sikora
Programista
aplikacji
internetowych
Temat: Node.js czy Apache/PHP
Tak, jasne. Uważam to za przyszłościową technologię i przy wykorzystaniu socketów sprawdza się świetnie.
Marek
Surma
Programista
aplikacji
internetowych.
Specjalista UX.
Temat: Node.js czy Apache/PHP
Tak się zastanawiam... czy nie byłoby dla Ciebie dobrym rozwiązaniem zaimplementowanie jakiegoś rozwiązania opartego na komunikacji:JavaScript <-> obiekt Flash (bez elementów wizualnych!) <-> serwer. Skąd to udziwnienie? Ano stąd, że możesz wtedy reagować w JS na event-y pochodzące z obiektu Flash. Podpinać się pod nie. Flash zająłby się komunikacją z siecią. Radzi sobie z tym lepiej niż JS. Po stronie serwera lepiej by było zastosować wtedy coś innego niż HTTP. Jasne... jakoś będzie działało i na HTTP. Nie wiem jak dynamiczna jest gra którą piszesz, ale nie ma co się spodziewać cudów. Long polling i jemu podobne to tylko półśrodki. Przy większej liczbie graczy się zemszczą. Tak czy inaczej podziwiam za próby korzystania z HTTP.
Maciej
Sikora
Programista
aplikacji
internetowych
Temat: Node.js czy Apache/PHP
Widzę, że nie zauważyłeś takiej możliwości jak web-socket dostępnej w html5. Long polling przechodzi do lamusa, a jedynym opóźnieniem socketów jest ruch w sieci i szybkość serwera
Marek
Surma
Programista
aplikacji
internetowych.
Specjalista UX.
Temat: Node.js czy Apache/PHP
Kto zauważył ten zauważył, ale ja bym w to nie wszedł ;)Byłoby to rozwiązaniem lecz polecam zobaczyć listę przeglądarek wspierających tą technologię:
http://caniuse.com/#feat=websockets
W tej chwili około połowa użytkowników nie mogłaby zagrać w grę bazującą na web-socket.
Programowałem kilka aplikacji opierających się na socket-ach i byłem bardzo zadowolony z ich działania. Było to wprawdzie pisane w C, ale jeżeli sockety dla przeglądarek zostaną powszechnie zaimplementowane, to stanę się także ich fanem! :)Marek Surma edytował(a) ten post dnia 01.05.11 o godzinie 23:15
Maciej
Sikora
Programista
aplikacji
internetowych
Temat: Node.js czy Apache/PHP
Marek Surma:
Kto zauważył ten zauważył, ale ja bym w to nie wszedł ;)
Byłoby to rozwiązaniem lecz polecam zobaczyć listę przeglądarek wspierających tą technologię:
http://caniuse.com/#feat=websockets
W tej chwili około połowa użytkowników nie mogłaby zagrać w grę bazującą na web-socket.
Programowałem kilka aplikacji opierających się na socket-ach i byłem bardzo zadowolony z ich działania. Było to wprawdzie pisane w C, ale jeżeli sockety dla przeglądarek zostaną powszechnie zaimplementowane, to stanę się także ich fanem! :)
Prawda jest taka, że zanim zrobisz coś konkretnego w tej technologii to minie tyle czasu, że już większość użytkowników będzie miała przeglądarki obsługujące web-socket.
Jakub L. Programista
Temat: Node.js czy Apache/PHP
Mnie zastanawia ten security issue.I jakbym miał serwer wuwuwu, to bym się zastanowił, czy bawiłyby mnie permanentnie otwarte połączenia do serwera.
Marek
Surma
Programista
aplikacji
internetowych.
Specjalista UX.
Temat: Node.js czy Apache/PHP
Maciej Sikora:
Prawda jest taka, że zanim zrobisz coś konkretnego w tej technologii to minie tyle czasu, że już większość użytkowników będzie miała przeglądarki obsługujące web-socket.
Przyznam że troszkę nie rozumiem. Co znaczy "coś konkretnego"? Na przykład chat online nie jest czymś konkretnym? Napiszę go w tej technologii w 3 dni. A wsparcie w przeglądarkach nawet nie wiadomo kiedy będzie :(((
Marek
Surma
Programista
aplikacji
internetowych.
Specjalista UX.
Temat: Node.js czy Apache/PHP
Jakub L.:
Mnie zastanawia ten security issue.
I jakbym miał serwer wuwuwu, to bym się zastanowił, czy bawiłyby mnie permanentnie otwarte połączenia do serwera.
Jeżeli pisząc "serwer wuwuwu" masz na myśli serwer HTTP, to to zależy. Ile osób ma sie podłączyć, co ma być przesyłane, w jakiej ilości i jak często. To są podstawowe pytania. Bez odpowiedzi nie jesteśmy w stanie określić jakie rozwiązanie jest dobre dla tego konkretnego projektu. HTTP nie jest przeznaczone do częstego odpytywania serwera. Pisząc częstego, mam na myśli kilka razy na sekundę. Nawet raz na sekundę może być problemem.
W przypadku gdybyśmy się uparli na to HTTP, to możemy uruchomić jakiś lekki serwer HTTP, albo wręcz napisać swój z obsługą tylko podstawowych komend dla tego protokołu. Taki powiedzmy APACHE jest zbyt ciężki do zastosowań tego typu.
