[AJAX][JavaScript][PHP]Zdalne wywołanie porcedury na klientach - hostach., Inicjowanie wywołania zdarzenia z serwera www na kodzie u klienta. Opcje

[fiasko]

Chcę zdalnie wywołać procedurę z serwera www na hoście u klienta w jego przeglądarce.

Chcę stworzyć np. chat za pośrednictwem serwera www.

Jak zdalnie na końcówce klienta wywołać żądanie pobrania zawartości wiadomości w momencie gdy do serwera dotrze wiadomość?

Zewnętrzny host nie może sam dobijać się na serwer przez odświeżanie. Serwer ma powiadomić hosta o wiadomości i dopiero wtedy on ją pobiera.


Chcę zrobić tak: klient uruchamia aplikację . Następnie loguje się do serwera , przesyła swoje IP i co 15 sek powiadamia serwer o swojej aktywności. Dzięki temu będę miał status .

To teraz jeszcze pytanie jak wysłać do przeglądarki dane z serwera i zainicjować wywołanie funkcji ?

Ten post edytował fiasko 20.04.2011, 00:03:24

[--zegarek84--]

jeśli chcesz to zrobić za pomocą JavaScript to musisz odpytać serwer - jednak nie musisz odpytywać go co sekundę - poczytaj o long poll ajax - można także posłużyć się innymi trickami jak JSONP do skryptu PHP itd. - lub skorzystaj z jakiegoś klienta napisanego we flashu do obsługi socketów współpracującego z JavaScript...

[fiasko]

A JSONP daje możliwość zdalnego wywołania funkcji w js ?

Proszę o przykładowe kody.

[wNogachSpisz]

Musisz przepytywać serwer co jakiś czas.

Long Poll? czyli wysyłanie zapytania losowo, powiedzmy co 1 - 5 sekund?
Bez większego sensu.

JSONP - script include?
Co to ma do rzeczy?

[fiasko]

No ale ja nie chcę przepytywać. Szukam rozwiązania , które samo wymusi inicjację . To ma działać na zasadzie RPC.

Ten post edytował fiasko 20.04.2011, 15:37:56

[wNogachSpisz]

No ale ja nie chcę przepytywać. Szukam rozwiązania , które samo wymusi inicjację . To ma działać na zasadzie RPC.

Nie da się, klient jest nieosiągalny dla serwera.
Inicjować połączenie musi klient.

[fiasko]

A to ktoś z was testował ?

http://www.tanabi.com/projects/jsonrpc

[#luq]

Nie da się, klient jest nieosiągalny dla serwera.
Inicjować połączenie musi klient.

Tam, pierdoły saskie...
http://nodejs.org/

[zegarek84]

A JSONP daje możliwość zdalnego wywołania funkcji w js ?

ogólnie tutaj jest zasada, iż w DHTML'u dołączasz do drzewa DOM zewnętrzny skrypt JS i nie musi to być JSON - tak więc tak - można zdalnie wywołać funkcję... a i adres do skryptu js nie musi się kończyć na js do plików statycznych gdyż może się odwoływać do skryptu php który oczywiście musi zwrócić poprawny kod JavaScript...

Long Poll? czyli wysyłanie zapytania losowo, powiedzmy co 1 - 5 sekund?
Bez większego sensu.

nie żadne losowe zapytanie do serwera - sprawdź pierwszy lepszy wynik w google ;/

JSONP - script include?
Co to ma do rzeczy?

to samo co long poll ajax - skrypt do którego się odwołasz nie musi od razu odesłać treści, może on sprawdzać czy coś zmieniło się na serwerze i gdy się zmieni wygenerować ową treść i wysłać - połączenie z serwerem będzie "wisiało" co prawda zainicjowane przez przeglądarkę, jednak zostanie zakończone albo po otrzymaniu odpowiedzi/przekroczeniu czasu oczekiwaniu/jakiś błąd...

Tam, pierdoły saskie...
http://nodejs.org/

kiedy to po prostu prawie jakby pisał w PHP tyle że po stronie serwera zmieni język na JavaScript [SSJS]... ale i tak jakby nie było musiałby mieć albo jakiegoś klienta obsługującego sockety np. we flashu lub skorzystać w JS ale po stronie klienta/przeglądarki [czyli z CSJS] z zasady podobnej jak to w long poll ajax...

zresztą odsyłam do bloga:
Komunikacja z serwerem w czasie rzeczywistym - oraz ewentualnych komentarzy gdzie wspomniałem o czystym JS...

Ten post edytował zegarek84 20.04.2011, 22:44:46

[wNogachSpisz]

Tam, pierdoły saskie...
http://nodejs.org/

Nie pierdoły, tylko dokładnie tak jest jak napisałem..

HA! HA! HA! - mało co nie pękłem ze śmiechu.
Co ma do tego wszystkiego node.js?
Przecież to technologia do obsługi serwera www.
Nie wprowadzania ona NIC w temacie ograniczeń warstwy transportowej.
A to właśnie tam jest bariera, serwer nie może być stroną rozpoczynającą negocjację połączenia i koniec!

zresztą odsyłam do bloga:
Komunikacja z serwerem w czasie rzeczywistym - oraz ewentualnych komentarzy gdzie wspomniałem o czystym JS...

Nie rozumiem, po jakiego grzyba ten flash?


P.S
Koniecznie zajrzyj na http://ajaxpatterns.org/

Ten post edytował wNogachSpisz 21.04.2011, 10:11:25

[zegarek84]

Nie rozumiem, po jakiego grzyba ten flash?

nie jest potrzebny flash chyba, że ktoś chce to zrobić na socketach - komunikację jak w temacie - sockety jeszcze nie we wszystkich przeglądarkach są wprowadzone - co do symulacji po stronie ajax też pisałem tam w komentarzach...

Nie wprowadzania ona NIC w temacie ograniczeń warstwy transportowej.
A to właśnie tam jest bariera, serwer nie może być stroną rozpoczynającą negocjację połączenia i koniec!

racja - nic dodać nic ująć

Co ma do tego wszystkiego node.js?
Przecież to technologia do obsługi serwera www.

ale tu trochu umniejszyłeś jego możliwości [choć fakt głównie do tego jest stosowany i powstał z myślą o SSJS], jest to fremwork ale głównie do obsługi socketów - więc za jego pomocą można zaimplementować dowolny serwer nie tylko WWW...

idąc dalej jeśli ktoś pisze w PHP i chciałby odciążyć serwer by oprócz zainicjowanych połączeń które muszą wisieć by serwer mógł w danej chwili odpowiedzieć by nie "wisiały" także ociężałe skrypty [ich procesy] PHP można napisać własny mini serwer WWW nasłuchujący na socketach by tylko jeden proces obsługiwał takie połączenia a nie cały tuzin i więcej - jednak jest to już trochu grubszy temat i skoro pojawiły się pytania o przykładowe skrypty to o tym chyba bez potrzeby wspominam... by nie pisać obsługi socketów od 0 do mini serwera można by skorzystać z jakiejś biblioteki lub je zmodyfikować - mi są znane tylko 2:
Nanoserv i phpsocketdaemon [małe stare porównanie między nimi]

jednak pisząc własny mini serwer gdzie proces będzie stale uruchomiony, trzeba pamiętać o kilku podstawowych zasadach - a przede wszystkim jednej - trzeba po sobie sprzątać gdyż może dojść do wycieku pamięci - czyli nieużywane zmienne null'ować lub unset'ować... i dobrze by to było napisać lub zaprojektować zdarzeniowo ;] - pozatym ze zmiennymi globalnymi a co za tym idzie także statystycznymi to trzeba ich używać z rozwagą by się nie zaplątać przy obsłudze różnych połączeń ^^

Ten post edytował zegarek84 21.04.2011, 10:22:34

[wNogachSpisz]

Rodzi się pytanie.
Po co pisać własny serwer www?
Są lepsze, Apache, lighttp.
PHP to ostatnie narzędzie jakiego bym użył do obsługi socketów.
Ponadto nie zadziała to na praktycznie żadnym hostingu www.
Nie potrafię doszukać się nawet cienia sensu w tym co wypisujesz.

Ten post edytował wNogachSpisz 21.04.2011, 10:31:52

[zegarek84]

Rodzi się pytanie.
Po co pisać własny serwer www?
Nie widzę szansy na jakikolwiek zysk.

przy obsłudze wielu połączeń opartych na zasadzie podtrzymanego połączenia jak long poll ajax lub dłuższej komunikacji z serwerem poprzez sockety np. przy wykorzystaniu flasha [także "wisi" połączenie] jeśli to wykonać bez serwera który sprawdza czy jest coś do wysłania i zarządza wszystkimi połączeniami w prostszej formie pisze się skrypta php gdzie w pętli musiałby sprawdzać na serwerze czy może już wysłać treść i jaką treść [mający jakiegoś sleep'a coby serwera nie zajechać] - bez serwera obsługującego te połączenia przy wielu połączeniach musi być uruchomionych wiele ociężałych skryptów [co za tym idzie wiele procesów] z całą otoczką z logiką podobną jak przy jednym mini serwerze gdzie trzeba sprawdzać czy coś wysłać i wstrzymywać połączenie... jest 10 połączeń to wisieć na np. sleepie i pętli sprawdzającej czy coś wysłać musi 10 skryptów i tak jeden do 1 - przy miniserwerze jeden proces obsługuje wszystkie połączenia na danym sockecie...

sorki ale jakoś nie umiem przelać tego na słowa i nie wiem, czy to jakoś strawnie opisałem...

PHP to ostatnie narzędzie jakiego bym użył do obsługi socketów.
Ponadto nie zadziała to na praktycznie żadnym hostingu www.
Nie potrafię doszukać się nawet cienia sensu w tym co wypisujesz.

o mini serwerze wspomniałem w celach optymalizacji - a więc już przy wielu połączeniach gdy w zasadzie ma się już serwer dedykowany... do prostych rozwiązań wystarczy jak skrypt i połączenie sobie po prostu będzie wisiało... skoro znasz inne języki to nie ma problemu napisać obsługę socketów w innym języku ;D - ogólnie przecież wszystko można napisać w całkiem innym języku - nawet w JavaScript [w końcu SSJS istniał także od dawna jednak nie był wykorzystywany głównie ze względu wcześniej na słaba wydajność - po za tym do obecnych rozwiązań w tym kierunku tez trzeba mieć dedyka ]

[wNogachSpisz]

Zamiast tej rzeźby, wystarczy dać:

Kod

Connection: Close