Newsgroup: it.comp.www.php
Titolo: Si può realizzare un servizio in php ?

Mi stavo chiedendo se si può realizzare un servizio in php e se ha
senso farlo (nel senso sarebbe una soluzione abbastanza robusta ?)
Con servizio intendo demone. Per esempio un programma sempre in
ascolto ad una certa porta e al ricevimento di un segnale scrive su
file o database.


Direttamente in php no
La cosa forse più comoda è apache che si comporta come demone e ti dà il 
vantaggio di tutto lo stack HTTP con relativi codici
Meglio ancora nginx
M
 
-- 
I fatti mi cosano

 vantaggio di tutto lo stack HTTP con relativi codici Meglio ancora nginx
 
Apache si comporta come demone nel senso stretto del termine, ma in Unix/
Linux non serve avere un demone per fornire un servizio.
 
Puoi fare uno script in PHP che viene richiamato come CLI da (x)inetd o 
equivalente.
A quel punto e` inetd che passa allo script i parametri in arrivo dal 
client, e lui funziona come una pagina web, solo che non emette (solo) 
HTML, ma deve stampare quello che interessa al client, in base al 
protocollo definito.
 
Non mi arrischierei a fare un intero demone in PHP, anche se penso che 
con le socket API si possa fare, perche` non e` proprio eccezionale nel 
forking di sottoprocessi, quindi avresti prestazioni scarse se non 
addirittura situazioni difficili o impossibili da gestire.
 
Bye.
 

 vantaggio di tutto lo stack HTTP con relativi codici
 
Questo è possibile soltanto se il client "parla" HTTP.
 
	Y.

 database.
 
Stai facendo un po' di confusione, "stare in ascolto su una stessa porta" 
lo si fa attraverso l'apertura / gestione  di un socket. L'invio dei 
segnali invece viene fatto attraverso le syscall del kernel.
 
 
Detto questo, la mia esperienza personale con php e programmi di questo 
tipo (apertura socket , fork , servizio, morte figlio) è pessima . 
È vero che sono anni che non ho più riprovato, magari con le versioni 
nuove di PHP la situazione è migliorata.
 
Personalmente consiglio python o C per questo tipo di applicazione.

 Personalmente consiglio python o C per questo tipo di applicazione.
 
Ringrazio tutti, in realtà ero scettico su questo utilizzo di php .
 
Ho chiesto perchè ho parlato con un amico che suppongo essere migliore
programmatore di me (anche se più orientato a tecnologie microsoft e
forse un po' arrugginito) e lui mi segnalava questa opzione ...
 
Anche io avevo pensato ai linguaggi che suggerivi tu
 
Questa domanda va inserita in un contesto più ampio, apro un altro
thread.
 
Grazie
 
 
 
 
 
 
 


Ok, ma permetterai che se si dovesse iniziare da zero e suando php 
mettere in mezzo apache invece di xinetd tolga un bel po' di possibili 
rogne



Php ho dei dubbi che riesca a stare in ascolto su un socket. Credo che 
in qualche maniera lo si debba attaccare ad un vero demone e a quel 
punto la vedo molto più comoda usare HTTP come protocollo dato che è 
iplementato in qualsiasi cosa
 
Altrimenti meglio andare di java o python
 
M
 
P.S.
io per i demonietti da poco trovo che l'accoppiata java + jetty sia 
fenomenale
Poche righe di codice e il demone è lanciabile a partire da un .jar


 iplementato in qualsiasi cosa
 
Io ho scritto un banale bot per IRC in php che svolge funzioni di 
moderazione automatica. Sta a tutti gli effetti in ascolto su un socket, 
senza problema alcuno.
 
-- 
Lorenzo Breda

 rogne
 
Se devi fare un webservice, si`.
 
Per qualsiasi protocollo che non sia HTTP, mettere in mezzo apache e` 
sbagliato, perche` non lo gestisce. :)
 
E piuttosto che tirarmi su tutto l'ambaradan di Java per un demone che 
magari deve solo fare una select su un db e restituire una stringa, 
preferisco farlo in PHP (o Python, o anche C, volendo farsi un po' piu` 
male).
 
Bye.
 


Ero della stessa idea finché non ho visto quanto facile sia diventato 
includere jetty direttamente nel jar.
Dieci righe di codice e hai la tua applicazione che parla felice con 
quel che ti pare. Per cose semplici in realtà credo ci voglia meno 
codice che per php.
Ovviamente poi dipende da quel che ci devi fare se sia adeguato o meno



E il socket come lo gestisce? Xinetd o qualche sistema nativo che non 
conosco?
M



Ah ecco il pezzo che mi mancava:
set_time_limit (0);
 
Non si finisce mai di imparare ...
Thx


 set_time_limit (0);
 
Che io ricordi l'interprete da CLI non ha limite di default. Tu pensavi 
di scrivere un demone che girasse all'interno di mod_php?


In realtà non è ci abbia pensato poi molto, se proprio dovessi fare una 
cosa così mi appoggerei allo stack HTTP di apache. Non ho mai provato a 
far andare indefinitamente uno script php, magari in ascolto su un 
socket. A naso credo che potrebbero esserci dei problemi non banali di 
gestione memoria, inoltre non potrebbe andare multithreaded
 
Dovendomi appoggiare a dei socket lo farei sicuramente in Java, ci si 
mette meno e la soluzione è sicuramente più testata.
Intrigante cmq come idea, una volta che avrò tempo da buttare farò una 
prova anche solo per il gusto di farlo


 Dovendomi appoggiare a dei socket lo farei sicuramente in Java,
 
Probabilmente hai familiarità con la piattaforma e gli strumenti.
Io direi perl/ruby/python a seconda dei gusti (a me piace Lua) ma a quel 
punto PHP è lo stesso.

 …in secondo luogo ora ti becca il Pellizzari e ti fa un cazziatone.
 
HAHAHA, e cosa sono? La Sacra Inquisizione? :D
 
Non ho mai provato in pratica a usare il multithreading di PHP, ma a me 
proprio non piace il multithread, preferisco il multiprocesso. Ha quasi 
le stesse prestazioni ma molti meno problemi di concorrenza.
 
PHP non e` certo a livello di Java per il multi-*, ma Go e` meglio di 
Java. ;P
 
Invece script PHP con durate anche abbastanza lunghe li ho provati e non 
mi hanno dato particolari problemi.
 
Come al solito dipende da cosa devi fare e quanto devi sbatterti.
 
Se conosci bene Java e snoccioli Thread come se fossero foreach, e sei 
disposto a tirarti dentro le decine di MB occupate dal minimo comun 
denominatore di un'applicazione Java, vai di Java.
 
Se (come me) conosci molto meglio PHP e puoi appoggiarti a xinetd per 
gestire la parte "socket", vai di PHP.
 
Se conosci Python e ti vuoi gestire i socket, la concorrenza, il 
multiprocesso (consapevole del biglock), vai di Python.
 
Se vuoi farti male a interfacciarti con SQL ma vuoi il massimo delle 
prestazioni col minimo della RAM occupata, vai di C.
 
Se sei un pioniere vai di Go o di Vala e buona fortuna. Torna e 
raccontami come e` andata che mi interessa molto! ;)
 
Bye.

 HAHAHA, e cosa sono? La Sacra Inquisizione? :D
 
;-) 
 
No, era per le accuse generiche al PHP. Innocente fino a prova contraria.

 le stesse prestazioni ma molti meno problemi di concorrenza.
 
In effetti l'estate sta finendo (.cit), e per affrontare il freddo non 
c'è niente di meglio di un flame thread VS fork !!
 
Red 
 
ps: spiegare pro e contro in 11 parole ,contate, è proprio una bella 
trollata! ;)
 
 


Now waaaaaaaait a minute, rollbacka la transaction :)
Io accuse non ne ho mosse, tantomeno generiche.
Non mi accusare di spargimento di FUD a gratis :)
 
Ho semplicemente detto che php non è sicuramente lo strumento canonico 
per la creazione di un demone che resti in ascolto su un socket.
Se un mio cliente mi chiedesse una realizzazione simile sicuramente lo 
farei in Java, non tanto perché mi venga più semplice, ma perché poi 
risulterebbe più mantenibile.
Trova tu un programmatore php che sappia poi metterci le mani. Bene per 
ognuno di quelli ne troverai 50 che sanno fare la stessa cosa in Java 
dato che storicamente il problema è stato risolto con quello strumento.
È un po' la motivazione per la quale consiglio php e symfony in 
particolare se c'è da fare un cms.
In Java si può, ma sicuramente trovi poi più gente pronta a gestirlo se 
lo fai in php
Ancora, nessun motivo prettamente tecnico, ma di fatto è così
 
Oltre a questo, io cerco di scrivere il più semplicemente e 
genericamente possibile in quanti più linguaggi riesco a maneggiare.
Per il momento mi limito a PHP Java e bash,
 
Peraltro ho appena fatto una cosa relativamente simile per un cliente.
Gli serviva un demone che tenesse sincronizzate delle cose remote/locale
Gli ho fatto un demone in php perché lo voleva in quel linguaggio. Un 
cron ajax che da browser continua a fare polling su uno scriptino (Io 
avevo consigliato un demonietto in Java, ma lui aveva paura 
dell'occupazione di memoria)
Poi ha voluto anche una applicazione GUI e l'ho fatta in Java
 
A me onestamente del linguaggio me ne cale poco, finché funziona ed è 
adeguato allo scopo che ci si prefigge. Io nello scopo metto sempre 
anche la soddisfazione a lungo periodo del cliente e se gli si dà in 
mano una soluzione semplice da mantenere è meglio (imho)
 
M
 
P.S.
Pellizzari non mi cazzia perché sennò smetto di dargli dritte su Kde ;)


 trollata! ;)
 
Guarda che se mi ci metto potrei trollare di fino! ;)
 
Mea culpa: mi sono sorbito per anni le discussioni thread vs processi in 
una buona meta` della gerarchia italiana, quindi do` un po' per scontato 
che le differenze si conoscano.
 
Inoltre per me "server = linux" (o Unix o BSD), quindi valuto su quello.
 
Impossibile stare sotto le 11 parole. :)
 
I thread condividono la memoria: sono piu` semplici da programmare, ma 
devi stare attento a non sovrascrivere aree di memoria gestite da altri 
thread.
 
I processi girano in memory space separati: e` piu` complicato farli 
comunicare, ma non rischi di sputtanare i dati su cui lavorano.
 
In Linux thread e processi sono implementati quasi tramite le stesse 
funzioni nel kernel, quindi il "peso" e` molto simile, anche grazie al 
copy-on-write e allo scheduler.
 
Bye.