Skripta mora biti stalno pokrenuta ako želiš da ona stalno prima podatke.

Potrebno ti je da napraviš socket, uradiš socket_bind i pokreneš socket_listen. Konekciju prihvataš sa socket_accept, i na raspolaganju ti je socket_read/socket_write.

Ako želiš više istovremenih konekcija, verovatno ćeš želeti da koristiš socket_set_nonblock i u while petlji socket_select da izabereš one sa kojih možeš da pročitaš podatke.

Kako da bude stalno aktivna?

Tako što ćeš socket_accept/socket_select pozivati u beskonačnoj petlji.

Beskonacna petlja???? To bas nece proci.
Cron i sleep kombinacija. Zavisi za koje brzine treba da je odziv.

VladaSu, o čemu govoriš? Ako njegov PHP daemon mora biti stalno dostupan (radi prijema podataka), kako to da izvede osim upotrebom beskonačne petlje u kojoj će prihvatati konekcije po napravljenom socketu koji osluškuje i sa njih primati podatke?

I ja sam razmisljao o Cronu, ali sam shvatio da nece ici, bas kao sto Goran kaze!

OK.Napisem skriptu. a kako da je "pustim u rad"?

Da je pozovem preko browsera? Mislim da to nece ici!?

Slobodno se smejte ako lupam! :D

Moraš da je pokreneš nezavisno od veb servera, inače će te runtime limit sprečiti u poduhvatu. Dakle možeš da je okineš iz terminala, ili ako nemaš takav pristup serveru, pokreneš je iz druge skripte sa system("/usr/bin/php skripta.php &") pozivom. Zavisno od postavke servera može opet postojati limit na korisničke procese ili putanja do php intepretatora može biti drugačija. U tom slučaju ćeš morati da menjaš postavke, server ili da se snalaziš sa tajmiranim pokretanjem druge skripte čim se prva ugasi.

Ja nemam pojima kako ces pokrenuti php skriptu koja u sebi ima beskonacnu petlju a da ne pukne.

S tim što će ti to (set_time_limit) raditi samo ako imaš svoj dedicated server koji si ti konfigurisao (čitaj: ni jedan normalan hosting provajder ti neće dozvoliti da ukineš time limit). I pored toga, moraćeš da držiš otvorenu tu stranicu u browseru sve vreme (za ovo nisam siguran, ali mislim da je tako) :S

Naravno da neće tu stranicu pokretati iz preglednika, već kao skript na serveru. Šta više to sam i napisao uz uslov "moraš".

Ne znam da li u ranijim verzijama, ili sam pomesao sa nekim drugim programskim jezikom, samo se nesto secam da se skripta sama gasila kada naidje na mrtvu petlju.
Probao i mrtva petlja prolazi u php-u ali procesor je skocio na 100% i tu se zakucao.
Inace moze skripta da se pokrene iz browser-a i da prilikom gubitka konekcija ona i dalje nastavi sa izvrsavanjem.
sleep mora da se koristi da ne bi server bio preopterecen.

primer sa php.net


ovde moze da prilikom prekida konekcije pokrene opet samu sebe.

Hm...kada se uradi socket_recvfrom, proces ostaje "zaboden" dok ne registruje dolazeci podatak!

U tom slucaju, nema uposlenog cekanja, pa sama petlja ne pretstavlja problem.

Da li gresim?

Mozda malo glupo pitanje, ali - zasto si odlucio da ovo radis preko PHP-a ? Slanje paketa - ok, moze, ali, primanje paketa - kao sto si vec primetio, malo moze da bude za*ebano.

PHP je napravljen sa idejom da se parsira (izvrsi) skripta i ugasi, al da konstantno radi i osluskuje neki port, huh ....

Koriscenje CRON-a, nisam bas siguran kolko bi pomoglo, jer, sta ako se desi da u trenutku kad se server (skripta koja osluskuje) ugasi, client pokusa da posalje paket ? Mislim da bi klijent odmah bacio gresku (osim ako mu ne nabudzis da proba recimo iz 3x). Al opet - razmisli da li je PHP najbolje resenje ? Mozda da pokusas sa nekim drugim laksim jezikom koji podrzava Thread-ove izmedju ostalog (Ruby/Python ja mislim da podrzavaju, ali - samo mislim).

Btw, nasao sam jedan dobar tutorial o kreiranju servera u PHP-u, pa ako ga vec nisi procitao, baci pogled - http://devzone.zend.com/article/1086

Btw2, pogledaj ono fork-ovanje, nikad ga nisam koristio ali sam cuo da predstavlja neku imitaciju Thread-ova ....

Btw3, ni ne pomisljaj da skriptu pokreces iz Browser-a :-D obavezno iz CLI-a i kao BG process (kao sto ti vec rece Goran) ;)

Pozz i javi sta si uradio/odlucio ;)

Ne grešiš, ali to je samo deo cele priče, a ja nisam siguran da si toga svestan. Razlikuje se način rada sa „konektujućim“ (SOCK_STREAM uz npr. TCP) i „nekonektujućim“ (SOCK_DGRAM uz npr. UDP) priključcima. Za druge je dovoljno socket_recvfrom, dok za prve moraš da imaš priključak konekcije (najpre socket_listen, pa onda socket_accept koji ti vrati novi priključak za konekciju kada se klijent zakači). Tek onda možeš da koristis socket_recv/socket_recvfrom.

Odgovor na tvoje pitanje, da svako blokirajuće čekanje ne predstavlja problem.

Edit: tek sada vidim UDP u naslovu. ;)




Ne postoji ni jedan razlog zašto ovo ne bi radilo iz PHP-a koji uredno prezentuje celokupan Unix Sockets sistemski interfejs. Razlozi da se odluči za PHP mogu biti u tome da za obradu komunikacije može da koristi već napisan PHP kod. I kada konstantno radi, skripta se samo jednom kompilira, ništa se neobično tu ne dešava.

Višenitno i višeprocesno programiranje nisu tesno vezani za prijem i slanje podataka, ali se često koriste kada je potrebno istovremeno primiti i duže obrađivati veći broj konekcija kao alternativa neblokirajućim funkcijama i redovima sa čekanjem. Postoje razni stilovi, sve zavisi od zahteva.

Zbog globalne brave (GIL), niti u Python-u su pseudoparalelne, dok su procesi analogni onima u PHP-u (man 2 fork).



_{[Ovu poruku je menjao Goran Rakić dana 02.04.2010. u 16:36 GMT+1]}

Jel neko uopšte ovo pokušavao?

http://www.phpclasses.org/browse/package/3736.html

Čovek kaže da je uradio DNS server, možda ovo i radi stvarno?

http://php.net/manual/en/function.pcntl-fork.php
Probaj koristeci fork, to mi nekako zvuci kao najlogicnije resenje (kao sto je neko vec naveo).

Sta tacno pokusavas da uradis (mislim zasto ti to treba)?
Mozda je bolji neki drugi jezik?

Borise, kakve fork ima veze sa temom?

Ljudi, "rasiriste ga do Moravu"! :D

Ovako:
poseban hardver salje podatke u intervalima od oko 15-20 sec serveru.
Mora se koristiti UDP iz dva razloga: prvi je kolicina podataka koju utrosi tcp/ip prenoseci gomilu, u ovom slucaju, nepotrebnih kontrolnih bitova; drugi razlog je taj sto udp ne zahteva konekciju sto je poseban zahtev jer uredjaj ne treba da trosi vreme na konekciju pri svakom slanju (15-20 sec)

Prihvatanje bi izgledalo ovako:



Kako proces ostaje "zaboden" na socket_recvfrom, to nece doci do nepotrbnog "trcanja" kroz petlju.

Pitanje jeste da li ce ovako mali interval prijema podataka mozda izazvati neke probleme server u vidu prevelikog zauzeca memorije ili cpu!?
Na lokalnom serveru, do toga nije dolazilo, ali videcu da li ce biti problema na hosterovom serveru.

U principu, mogao bih podesiti da se u odredjenom vremenskom intervalu proces sam killuje, a pre toga pokrene novi sa istom funkcijom.

@Goran Rakic
Recimo iskoristis ovu klasu (malo modifikujes da slusas port) http://www.php.net/manual/en/ref.pcntl.php#82373
Kad port javi da ima necega ti izvrsis odredjenu radnju koja ti treba i to je to.
Meni ovo nekako izgleda kao resenje, gledao sam malo po netu i vidim da ljudi koriste taj nacin i pear za system:deamon http://pear.php.net/package/System_Daemon
Takodje iskopah negde neki projekat koje je ovo postigao Gearman http://gearman.org/

Sve mi ovo lici na multi threading. Pretpostavljam da je zahtev da se napravi chat aplikacija?

P.S. Video sam i negde da je neko napravio da slusa bazu i onda u koliko unese recimo test u bazu jedan child process se ubije, parent process se ugasi tek posto se ugase svi child procesi.

p.p.s. google moj najbolji prijatelj :D

Kao što rekoh, komunikacija preko priključaka nije nužno vezana za višenitno i višeprocesno programiranje. Linkovi koje navodiš veze sa temom nemaju.

Nebih da ovo razvlacim u neku medjusobnu diskusiju, ipak je ovo diskusija na temu a ne ocenjivanje tudjeg rada.
Ne vidim kako su moji linkovi promasena tema, ali mozda i gresim (ta svi mi gresimo zato smo ljudi).

Ako bi mogao da postavis svoj kod kako si to resio, voleo bih da vidim, a i bilo bi poucno (da malo vidimo koda za razliku od price).
Ne kazem da nije moguce uraditi drugacije, verovatno postoji lepse resenje.

UPDATE: Izvinjenje, videh sad da je u ranijim postovima proces opisan.

_{[Ovu poruku je menjao b0ris dana 03.04.2010. u 14:48 GMT+1]}