Re: Alternativa correcta (socket daemon)
Hector Salinas escribió: Hola Listeros : ... Ps: necesito una repuesta constructiva, antes de que me tiren a los Leones ¿Ven como fomentan el miedo a realizar preguntas? (Al que le llegue) -- Atte. Ricardo Utreras Estrella
Re: Alternativa correcta (socket daemon)
>El drama que tengo es el siguiente(o no se sin tan drama). La > aplicación la realice con PHP-Cli (era lo que > por alguna extraña razon el script deja defunciona como demonio y tengo ¿deja de funcionar sola? ¿deja de funcionar cuando responde? ¿deja de funcionar despues de un rato? no conozco php-cli pero como parece ser php intenta poniendo set_time_limit ( 0 ); al inicio, asi no se va por time out ¿manejas las señales del sistema? http://cl.php.net/manual/en/ref.pcntl.php ¿ya le pusiste un debug en cada linea para ver donde se cae?
Re: Alternativa correcta (socket daemon)
Hola Listeros : necesito una ayuda de uds. Por favor Hace un mes que tengo leyendo sobre la programación al socket y sobre deamon En linux. Resulta que realice un aplicación (o pequeño script )que escucha en el puerto 5000 (socket) Y esta corriendo como demonio (la aplicación escucha desde un torniquete. él envía el código pdf147 a la aplicación , la aplicación Consulta al DBMS(mysql). si existe el persona devuelve una "A" al torniquete para activarlo, de lo contrario La persona no entra). Hasta este punto todo Bien El drama que tengo es el siguiente(o no se sin tan drama). La aplicación la realice con PHP-Cli (era lo que mas tenia a mano Ya que si no se hacia un aplicación rápidamente, se implementaba con la que venia con el torniquete y esta esta hecha en VB 6 :( ) por alguna extraña razón el script deja de funcionar como demonio y tengo que volver a ejecutar para que continúe escuchando al torniquete y eso me tiene loco (y llego a la conclusión De que php-cli no me sirve). El OS que esta corriendo es CentOS 5.2 (como me gusta esta distro) al dia Las preguntas son 1.- ¿ la ca/&¬€~#· en hacerlo en php-cli? yep 2.- ¿ que lenguaje tendría que usar para este tipo de uso (c, java, python o algún otro que desconozco) ? c , python, perl, gambas... cualquiera que puedas generar un binario para ejecutarlo como demonio. nota: al que hiciste, tendrías que hacer que "refresque cada x segundos, lo cual no es muy bueno que digamos. Ps: necesito una repuesta constructiva, antes de que me tiren a los Leones nop, apenas para cucho de azotea te alcanzo ;-) Enrique Herrera Noya enrique.herr...@linuxcenterla.com Relator y Encargado de Atencion a Universidades y Comunidad Linux 56-2-4834140 09-92303151
Re: Alternativa correcta (socket daemon)
Juan Manuel Doren escribió: > >El drama que tengo es el siguiente(o no se sin tan drama). > > La aplicación la realice con PHP-Cli (era lo que > > por alguna extraña razon el script deja defunciona como demonio y tengo > > ¿deja de funcionar sola? > ¿deja de funcionar cuando responde? > ¿deja de funcionar despues de un rato? > > no conozco php-cli pero como parece ser php intenta poniendo > set_time_limit ( 0 ); > al inicio, asi no se va por time out Tambien puede ser porque exceda el límite de memoria, en caso de que el programa tenga una fuga de memoria (memory leak). Los programas en PHP usualmente se cierran sin mayores aspavientos cuando eso pasa. En este caso, sospecho que la única manera es asegurarse de que el programa libera bien toda su memoria; por ej. evitar usar variables globales, de forma que la memoria que usan se libere automáticamente cuando queden fuera de ámbito (scope). La manera de verificar esto es monitorear el uso de memoria de la aplicacion en el transcurso del tiempo. -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 Si no sabes adonde vas, es muy probable que acabes en otra parte.
RE: Alternativa correcta (socket daemon)
>El drama que tengo es el siguiente(o no se sin tan > drama). La aplicación la realice con PHP-Cli (era lo que por alguna > extraña razon el script deja defunciona como demonio y tengo >>¿deja de funcionar sola? Se cae como proceso y no muestra nada en los log, >>¿deja de funcionar cuando responde? ??? >>¿deja de funcionar despues de un rato? Es relativo, escucha una 200 peticion y se cae como proceso, luego escucha unas 300 y pasa lo mismo Puede hasta escuchar 20 peticiones y pasa >>no conozco php-cli pero como parece ser php intenta poniendo set_time_limit ( 0 ); al inicio, asi no se va por time out Esa funcion ya la tengo al princio del script >>¿manejas las señales del sistema? >>http://cl.php.net/manual/en/ref.pcntl.php Estoy en ese lugar leyendo algo que pueda ayudar >>¿ya le pusiste un debug en cada linea para ver donde se cae? Cree una salida a los log del sistema (funcion syslog) y nada extraño y no tengo sobrecarga en el server tampoco __ Information from ESET NOD32 Antivirus, version of virus signature database 3790 (20090122) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: Alternativa correcta (socket daemon)
Hector Salinas escribió: > > >El drama que tengo es el siguiente(o no se sin tan > > drama). La aplicación la realice con PHP-Cli (era lo que por alguna > > extraña razon el script deja defunciona como demonio y tengo > > >>¿deja de funcionar sola? > > Se cae como proceso y no muestra nada en los log, Suena harto al problema de memoria que comentaba en el otro mail. PHP simplemente llama a exit() y chao. -- Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4 "In fact, the basic problem with Perl 5's subroutines is that they're not crufty enough, so the cruft leaks out into user-defined code instead, by the Conservation of Cruft Principle." (Larry Wall, Apocalypse 6)
Re: Alternativa correcta (socket daemon)
Hola Hector, Por tu comentario acerca de que "tu aplicacion deja de funcionar", quizas el error esta en "como" esta hecho el server y no en el lenguaje/interprete que fue utilizado para hacerlo. Sobre tus preguntas: 1) No creo que hayas cometido un error en usar PHP, si bien yo no lo recomendaria para hacer un servidor, eso no significa que no pueda cumplir con el objetivo, si tu objetivo es concurrencia y escalabilidad... fue una mala eleccion y debio ser hecho en C. 2) Si deseas reescribirlo deberias evaluar: a) Tiempo que tienes para reescribirlo y que nivel de conocimiento tienes en cada lenguaje (no utilizaras el mismo tiempo para hacer un server en python que uno en C) b) ¿ Tendra el server altos niveles de concurrencia ? 500 consultas por segundo ?? Opinion personal: Si es un server que no tendra mucha concurrencia y los tiempos de respuesta no son criticos, yo te recomendaria hacerlo en Python, de lo contrario en C. saludos. -- Eduardo Silva http://edsiper.linuxchile.cl 2009/1/22 Ricardo Utreras Estrella > Hector Salinas escribió: > >>Hola Listeros : >> ... >> Ps: necesito una repuesta constructiva, antes de que me tiren a los Leones >> > > > ¿Ven como fomentan el miedo a realizar preguntas? (Al que le llegue) > > -- > Atte. Ricardo Utreras Estrella > >
Re: Alternativa correcta (socket daemon)
> > 1) No creo que hayas cometido un error en usar PHP, si bien yo no lo > recomendaria para hacer un servidor, eso no significa que no pueda cumplir > con el objetivo, si tu objetivo es concurrencia y escalabilidad... fue una > mala eleccion y debio ser hecho en C. yo tengo programas hechos en php que corren durante mas de una semana sin problemas y terminan cuando tienen que hacerlo ¿mi razon de usar php y no c, c++ o python o assembler? esos programas son parte de un sistema web hecho en php+sql+html+javascript ¿para que agregar un lenguaje mas si el programa en cuestion a de ser el 1% de todo el sistema? asi que la eleccion de la herramienta depende de muchas cosas, puede que php-cli haya sido __tu__ mejor opcion
Re: Alternativa correcta (socket daemon)
Alvaro Herrera escribió: Hector Salinas escribió: El drama que tengo es el siguiente(o no se sin tan drama). La aplicación la realice con PHP-Cli (era lo que por alguna extraña razon el script deja defunciona como demonio y tengo ¿deja de funcionar sola? Se cae como proceso y no muestra nada en los log, Suena harto al problema de memoria que comentaba en el otro mail. PHP simplemente llama a exit() y chao. voy a probar cambiando la configuracion del php.ini, por que estoy usando la que viene por defecto en la instalación(la maquina tiene 512MB)
Re: Alternativa correcta (socket daemon)
On Thu, 2009-01-22 at 12:31 -0300, Hector Salinas wrote: > Hace un mes que tengo leyendo sobre la programacion al socket > y sobre deamon En linux. Resulta que realice un aplicación (o > pequeño script) que escucha en el puerto 5000 (socket) Y esta > corriendo como demonio (la aplicación eschucha desde un tornique. él > envia el codigo pdf147 a la aplicacion, la aplicación Consulta al > DBMS(mysql). si exite el persona devuelve una "A" al torniquete para > activarlo, de lo contrario La persona no entra). Hasta este punto > todo Bien Bien, se ve facil. > El drama que tengo es el siguiente(o no se sin tan drama). La > aplicación la realice con PHP-Cli (era lo quemas tenia a mano Ya que > si no se hacia un aplicación rapidamente, se implentaba con la que > venia con el torniquete y esta esta hecha en VB 6 :( ) por > alguna extraña razon el script deja defunciona como demonio y tengo > que volve a ejecutar para que continue escuchando al > torniquete y eso me tiene loco (y llego a la conclusion De que > php-cli no me sirve). Puedes agregar tu script PHP en /etc/inetd.conf y lo programas como si lee/escribe desde la entrada estandar. Ejemplo en BASH: amar...@videopodcast:~$ tail -1 /etc/inetd.conf 9876 stream tcp nowait nobody /home/amartoq/ej.sh amar...@videopodcast:~$ cat /home/amartoq/ej.sh #!/bin/bash echo -n "Bienvenido.. su nombre? " read NOMBRE echo "HOLA $NOMBRE" amar...@videopodcast:~$ telnet localhost 9876 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Bienvenido.. su nombre? Aldrin HOLA Aldrin Connection closed by foreign host. > El OS que esta corriendo es CentOS 5.2 (como me gusta esta distro) al dia > Las preguntas son > 1.- ¿ la ca/&¬€~#· en hacerlo en php-cli? No necesariamente... > 2.- ¿ que lenguaje tendria que usar para este tipo de uso (c, java, python o > algun otro que desconosco) ? Yo te recomiendo python (es realmente facil y elegante, no te costara aprender). Lo que tienes que hacer: 1.- escribir una funcion que haga la pega y probarla 2.- embutir la funcion en un servidor socket. Ejemplo: http://danieldandrada.blogspot.com/2007/09/python-socketserverthreadingtcpserver.html 3.- poner tu programa en /etc/inittab; asi se levanta automaticamente La diferencia con el ejemplo bash/inetd es que esto sera un poco mas "performante" y aprenderas python de paso ;) -- Aldrin Martoq http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: Alternativa correcta (socket daemon)
hsalinas escribió: > Alvaro Herrera escribió: >> Hector Salinas escribió: >>> El drama que tengo es el siguiente(o no se sin tan drama). La aplicación la realice con PHP-Cli (era lo que por alguna extraña razon el script deja defunciona como demonio y tengo > ¿deja de funcionar sola? >>> Se cae como proceso y no muestra nada en los log, >> >> Suena harto al problema de memoria que comentaba en el otro mail. PHP >> simplemente llama a exit() y chao. >> > voy a probar cambiando la configuracion del php.ini, por que estoy > usando la que viene por defecto en la instalación(la maquina tiene 512MB) Claro, para probar si es eso, es buena idea (pero no tanto -- ver mas abajo). Pero obviamente si encuentras que ese es el problema, entonces vas a tener que realmente corregir el error arreglando tu programa. Por que digo que puede no ser tan buena idea; resulta que me acorde que dijiste que a veces se cierra despues de 200 iteraciones, otras veces a las 300, otras veces a las 30. Lo que no me queda claro es como vas a saber, si aumentas la memoria, si se cierra ahora en 300 porque iba a durar 30 y se demoro 10 veces mas, o porque se iba a demorar 300 con o sin el cambio. -- Alvaro Herrerahttp://www.advogato.org/person/alvherre "A wizard is never late, Frodo Baggins, nor is he early. He arrives precisely when he means to." (Gandalf, en LoTR FoTR)
Re: Alternativa correcta (socket daemon)
Eduardo Silva escribió: Hola Hector, Hola Eduardo Por tu comentario acerca de que "tu aplicacion deja de funcionar", quizas el error esta en "como" esta hecho el server y no en el lenguaje/interprete que fue utilizado para hacerlo. Sobre tus preguntas: 1) No creo que hayas cometido un error en usar PHP, si bien yo no lo recomendaria para hacer un servidor, eso no significa que no pueda cumplir con el objetivo, si tu objetivo es concurrencia y escalabilidad... fue una mala eleccion y debio ser hecho en C. 2) Si deseas reescribirlo deberias evaluar: a) Tiempo que tienes para reescribirlo y que nivel de conocimiento tienes en cada lenguaje (no utilizaras el mismo tiempo para hacer un server en python que uno en C) estoy pensando en eso b) ¿ Tendra el server altos niveles de concurrencia ? 500 consultas por segundo ?? las hora pick que se utiliza el script son de las 7:00 a las 9:00 en la mañana y en la tarde de 17:30 a 20:00 y dentro de esos rangos consulta cada 5 a 7 segundo consulta la DBMS(que es el tiempo que se demora un persona en pasar un toniquete) ¿eso es alto? Opinion personal: Si es un server que no tendra mucha concurrencia y los tiempos de respuesta no son criticos, yo te recomendaria hacerlo en Python, de lo contrario en C. estoy mirando a monty python
Re: Alternativa correcta (socket daemon)
2009/1/22 Hector Salinas > >Hola Listeros : > > necesito una ayuda de uds. Por favor > > >Hace un mes que tengo leyendo sobre la programacion al socket > y sobre deamon > >En linux. Resulta que realice un aplicación (o pequeño script )que > escucha en el puerto 5000 (socket) > >Y esta corriendo como demonio (la aplicación eschucha desde un > tornique. él envia el codigo pdf147 a la aplicacion > >, la aplicación Consulta al DBMS(mysql). si exite el persona devuelve > una "A" al torniquete para activarlo, de lo > >contrario La persona no entra). Hasta este punto todo Bien > >El drama que tengo es el siguiente(o no se sin tan drama). La > aplicación la realice con PHP-Cli (era lo que > >mas tenia a mano Ya que si no se hacia un aplicación rapidamente, se > implentaba con la que venia con el torniquete y >esta esta hecha en VB 6 :( ) por alguna extraña razon el script deja > defunciona como demonio y tengo > >que volve a ejecutar para que continue escuchando al torniquete y eso > me tiene loco (y llego a la conclusion >De que php-cli no me sirve). > >El OS que esta corriendo es CentOS 5.2 (como me gusta esta > distro) al dia > > >Las preguntas son > >1.- ¿ la ca/&¬€~#· en hacerlo en php-cli? > >2.- ¿ que lenguaje tendria que usar para este tipo de uso (c, java, > python o algun otro que desconosco) ? > > > > Ps: necesito una repuesta constructiva, antes de que me tiren a los Leones > > > > > > > > > > > > > __ Information from ESET NOD32 Antivirus, version of virus signature > database 3787 (20090121) __ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > __ Information from ESET NOD32 Antivirus, version of virus signature > database 3787 (20090121) __ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > si lo haces en forma correcta con algun tipo de controlador que verifique que el dominio no se cae y demas puedes hacerlo perfectamente en PHP te dejo una url en ingles sobre la construccion de daemons en PHP http://kevin.vanzonneveld.net/techblog/article/create_daemons_in_php/ creo que con esto te puedes guiar para hacer correctamente el script y seguir con la base que tienes de PHP. -- Horacio Degiorgi http://codigophp.com Mendoza - Argentina
Re: Alternativa correcta (socket daemon)
Horacio Degiorgi escribió: 2009/1/22 Hector Salinas si lo haces en forma correcta con algun tipo de controlador que verifique que el dominio no se cae y demas puedes hacerlo perfectamente en PHP te dejo una url en ingles sobre la construccion de daemons en PHP http://kevin.vanzonneveld.net/techblog/article/create_daemons_in_php/ creo que con esto te puedes guiar para hacer correctamente el script y seguir con la base que tienes de PHP. -- Horacio Degiorgi http://codigophp.com Mendoza - Argentina Gracias Horacio. Pero ya pase por ese lado, lo probe en mi flamente CentOS pero la clase que esta en pear-php esta aun en estado beta y medio un monto de problemas
Re: Alternativa correcta (socket daemon)
On Thu, 2009-01-22 at 12:31 -0300, Hector Salinas wrote: > Hola Listeros : > Hola > necesito una ayuda de uds. Por favor > > > Hace un mes que tengo leyendo sobre la programacion al socket y > sobre deamon > > En linux. Resulta que realice un aplicación (o pequeño script )que > escucha en el puerto 5000 (socket) > > Y esta corriendo como demonio (la aplicación eschucha desde un > tornique. él envia el codigo pdf147 a la aplicacion > > , la aplicación Consulta al DBMS(mysql). si exite el persona devuelve > una "A" al torniquete para activarlo, de lo > > contrario La persona no entra). Hasta este punto todo Bien > > El drama que tengo es el siguiente(o no se sin tan drama). La > aplicación la realice con PHP-Cli (era lo que > > mas tenia a mano Ya que si no se hacia un aplicación rapidamente, se > implentaba con la que venia con el torniquete y > esta esta hecha en VB 6 :( ) por alguna extraña razon el script deja > defunciona como demonio y tengo > > que volve a ejecutar para que continue escuchando al torniquete y eso > me tiene loco (y llego a la conclusion > De que php-cli no me sirve). Como ejecutas la aplicación ? desde linea de comando en una terminal ? vía ssh ? Cuando revisas si esta corriendo muestra algún error la terminal ? explayarse al respecto. > El OS que esta corriendo es CentOS 5.2 (como me gusta esta > distro) al dia > ok > > Las preguntas son > > 1.- ¿ la ca/&¬€~#· en hacerlo en php-cli? No necesariamente...quizás algo ocurre pero no das mucha información... > 2.- ¿ que lenguaje tendria que usar para este tipo de uso (c, java, > python o algun otro que desconosco) ? > El que mejor domines. > > > Ps: necesito una repuesta constructiva, antes de que me tiren a los Leones > :) ok. Por pura curiosidad, ejecuta tu script desde linea de comando con "nohup" : http://www.vicente-navarro.com/blog/2007/04/19/sobre-la-senal-sighup-nohup-disown-trap/ Ojala te ayude. > > > > > > > > > > > __ Information from ESET NOD32 Antivirus, version of virus signature > database 3787 (20090121) __ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > > __ Information from ESET NOD32 Antivirus, version of virus signature > database 3787 (20090121) __ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > >
Re: Alternativa correcta (socket daemon)
Alvaro Avello escribió: On Thu, 2009-01-22 at 12:31 -0300, Hector Salinas wrote: Hola Listeros : Como ejecutas la aplicación ? desde linea de comando en una terminal ? vía ssh ? Cuando revisas si esta corriendo muestra algún error la terminal ? explayarse al respecto. la ejecuta desde un terminal (al principio la ejecutaba con & para que pasara como proceso (igual terminaba inesperamente) y con algunas funciones de php-cli la manda como demonio sin necesidad del &) la he ejecutado usan con el comando screen (cuando usaba &) pero ahora ya no, ademas la tengo en el rc.local y tambien termina repentinamente no muestra ningun error en el terminal El que mejor domines. php Por pura curiosidad, ejecuta tu script desde linea de comando con "nohup" : http://www.vicente-navarro.com/blog/2007/04/19/sobre-la-senal-sighup-nohup-disown-trap/ Ojala te ayude. ire de inmediato a visitar ese link, gracias
Re: Alternativa correcta (socket daemon)
>estoy pensando en eso > que bien :) > > >> b) ¿ Tendra el server altos niveles de concurrencia ? 500 consultas por >> segundo ?? >> > > las hora pick que se utiliza el script son de las 7:00 a las 9:00 en la > mañana y en la tarde de 17:30 a 20:00 y dentro de esos rangos consulta cada > 5 a 7 segundo consulta la DBMS(que es el tiempo que se demora un persona en > pasar un toniquete) > > ¿eso es alto? > bajisimo, no debieses tener mayores problemas. > > > > >> Opinion personal: Si es un server que no tendra mucha concurrencia y los >> tiempos de respuesta no son criticos, yo te recomendaria hacerlo en >> Python, >> de lo contrario en C. >> > > estoy mirando a monty python hace run server en python es muy simple... ;) -- Eduardo Silva http://edsiper.linuxchile.cl
Re: Alternativa correcta (socket daemon)
On Thu, 2009-01-22 at 22:20 -0300, hsalinas wrote: > Alvaro Avello escribió: > > Por pura curiosidad, ejecuta tu script desde linea de comando con > > "nohup" : > > http://www.vicente-navarro.com/blog/2007/04/19/sobre-la-senal-sighup-nohup-disown-trap/ > > Ojala te ayude. > ire de inmediato a visitar ese link, gracias nohup es lo mas horripilante que puedes implementar; algunos contras: 1.- el log (stdout) no lo puedes rotar 2.- si se cae tienes que levantarlo igual 3.- es fuera de norma... Ejecutar nohup /home/amartoq/pepito.sh & para levantar servicio X requiere documentacion y entrenamiento para los que vendran 4.- Me recuerda esos "demonios" java corriendo en windows: hay una consola, esta tomada y no podemos matarla, no sabes que esta gritando en stdout; pero algo (bueno) debe estar haciendo.. O haces un servicio de adeveras (que no se caiga, multiproceso y se convierte en demonio, logrotate y un /etc/init.d/servicio decentito) _o_ agregas una entrada en tu /etc/inittab (tu programa es picante, se cae a pedazos, nadie sabe que hace, pero al menos alguien lo levantara automaticamente)... asi que nohup no es una opcion, nunca... por favor... -- Aldrin Martoq http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: Alternativa correcta (socket daemon)
On Fri, 2009-01-23 at 02:46 -0300, Aldrin Martoq wrote: > On Thu, 2009-01-22 at 22:20 -0300, hsalinas wrote: > > Alvaro Avello escribió: > > > Por pura curiosidad, ejecuta tu script desde linea de comando con > > > "nohup" : > > > http://www.vicente-navarro.com/blog/2007/04/19/sobre-la-senal-sighup-nohup-disown-trap/ > > > Ojala te ayude. > > ire de inmediato a visitar ese link, gracias > > nohup es lo mas horripilante que puedes implementar; algunos contras: > 1.- el log (stdout) no lo puedes rotar > 2.- si se cae tienes que levantarlo igual > 3.- es fuera de norma... Ejecutar nohup /home/amartoq/pepito.sh & para > levantar servicio X requiere documentacion y entrenamiento para los que > vendran > 4.- Me recuerda esos "demonios" java corriendo en windows: hay una > consola, esta tomada y no podemos matarla, no sabes que esta gritando en > stdout; pero algo (bueno) debe estar haciendo.. > > Jajajaja...muchos de esos en el mercado... > > O haces un servicio de adeveras (que no se caiga, multiproceso y se > convierte en demonio, logrotate y un /etc/init.d/servicio decentito) _o_ > agregas una entrada en tu /etc/inittab (tu programa es picante, se cae a > pedazos, nadie sabe que hace, pero al menos alguien lo levantara > automaticamente)... asi que nohup no es una opcion, nunca... por > favor... > > Es cierto..no es muy "fancy" utilizarlo... Pero entonces si descartamos nohup, la pregunta del millón : como registrar los errores de un programa que no registra errores ? inhibir la supresión de errores del php.ini ? que registre en un archivo todo lo que hace el programa ? Sorry, solo preguntas y pocas respuestas. Saludos, >
Re: Alternativa correcta (socket daemon)
Alvaro Avello escribió: On Fri, 2009-01-23 at 02:46 -0300, Aldrin Martoq wrote: On Thu, 2009-01-22 at 22:20 -0300, hsalinas wrote: > Alvaro Avello escribió: > > Por pura curiosidad, ejecuta tu script desde linea de comando con > > "nohup" : > > http://www.vicente-navarro.com/blog/2007/04/19/sobre-la-senal-sighup-nohup-disown-trap/ > > Ojala te ayude. > ire de inmediato a visitar ese link, gracias nohup es lo mas horripilante que puedes implementar; algunos contras: 1.- el log (stdout) no lo puedes rotar 2.- si se cae tienes que levantarlo igual 3.- es fuera de norma... Ejecutar nohup /home/amartoq/pepito.sh & para levantar servicio X requiere documentacion y entrenamiento para los que vendran 4.- Me recuerda esos "demonios" java corriendo en windows: hay una consola, esta tomada y no podemos matarla, no sabes que esta gritando en stdout; pero algo (bueno) debe estar haciendo.. Jajajaja...muchos de esos en el mercado... O haces un servicio de adeveras (que no se caiga, multiproceso y se convierte en demonio, logrotate y un /etc/init.d/servicio decentito) _o_ agregas una entrada en tu /etc/inittab (tu programa es picante, se cae a pedazos, nadie sabe que hace, pero al menos alguien lo levantara automaticamente)... asi que nohup no es una opcion, nunca... por favor... Es cierto..no es muy "fancy" utilizarlo... Pero entonces si descartamos nohup, la pregunta del millón : como registrar los errores de un programa que no registra errores ? inhibir la supresión de errores del php.ini ? que registre en un archivo todo lo que hace el programa ? Sorry, solo preguntas y pocas respuestas. Saludos, Buenos dias a todos : anoche estube estudiando sus comentario (que los agrasco) y tratar de buscar una solucion aplique unas configuracion en el script (ademas toque el php.ini). Hoy para variar en la mañana se volvio a caer inesperadamente el script, nada en los log y ningun mensaje en la consola, ahora lo volvi a subir pero con el comando nohup para ver su salida (luego comento que pasa)
Re: Alternativa correcta (socket daemon)
On 1/22/09, Eduardo Silva wrote: > Hola Hector, > > Por tu comentario acerca de que "tu aplicacion deja de funcionar", quizas el > error esta en "como" esta hecho el server y no en el lenguaje/interprete que > fue utilizado para hacerlo. > > Sobre tus preguntas: > > 1) No creo que hayas cometido un error en usar PHP, si bien yo no lo > recomendaria para hacer un servidor, eso no significa que no pueda cumplir > con el objetivo, si tu objetivo es concurrencia y escalabilidad... fue una > mala eleccion y debio ser hecho en C. > > 2) Si deseas reescribirlo deberias evaluar: > > a) Tiempo que tienes para reescribirlo y que nivel de conocimiento tienes en > cada lenguaje (no utilizaras el mismo tiempo para hacer un server en python > que uno en C) > > b) ¿ Tendra el server altos niveles de concurrencia ? 500 consultas por > segundo ?? > > Opinion personal: Si es un server que no tendra mucha concurrencia y los > tiempos de respuesta no son criticos, yo te recomendaria hacerlo en Python, > de lo contrario en C. A que viene esto? Las diferencias entre python y c no son abismantes como para hacer tales recomendaciones. El hecho de que sea interpretado, no es, por si mismo, sinónimo de lentitud. > > saludos. > > > -- > Eduardo Silva > http://edsiper.linuxchile.cl > > > 2009/1/22 Ricardo Utreras Estrella > >> Hector Salinas escribió: >> >>>Hola Listeros : >>> ... >>> Ps: necesito una repuesta constructiva, antes de que me tiren a los >>> Leones >>> >> >> >> ¿Ven como fomentan el miedo a realizar preguntas? (Al que le llegue) >> >> -- >> Atte. Ricardo Utreras Estrella >> >> > -- Saludos, LSM. Existen 10 tipos de personas: los que entienden binarios y los que no
Re: Alternativa correcta (socket daemon)
>anoche estube estudiando sus comentario (que los agrasco) y > tratar de buscar una solucion aplique unas configuracion en el script > (ademas toque el php.ini). Hoy para variar en la mañana se volvio a caer > inesperadamente el script, nada en los log y ningun mensaje en la consola, > > ahora lo volvi a subir pero con el comando nohup para ver su salida (luego > comento que pasa) si tienes espacio en disco graba un log con todo lo que hace y un flush() en cada escritura si lo que quieres es hacer debug no uses nohup, abre el proceso en una consola como cualquier programa, primero concentrate en que sea estable y despues en demonizarlo si no te puedes dar el lujo de que el proceso este abajo un rato metelo en un loop algo asi: #while(true) do echo "prtieron"; date;./miscript.sh; free >>error.log;date >>error.log;done
Re: Alternativa correcta (socket daemon)
>> >> Opinion personal: Si es un server que no tendra mucha concurrencia y los >> tiempos de respuesta no son criticos, yo te recomendaria hacerlo en Python, >> de lo contrario en C. > A que viene esto? Las diferencias entre python y c no son abismantes > como para hacer tales recomendaciones. El hecho de que sea > interpretado, no es, por si mismo, sinónimo de lentitud. >> en el caso de un demonio el que sea interpretado o compilado da casi lo mismo, porque el interprete compila una vez como por una centesima de segundo y despues el proceso esta compilado en memoria por horas, dias, semana o meses el problema es el uso de memoria y recursos del sistema pero con equipos de 4GB de memoria ram y 4 nucleos, tampoco es dramatico lo importante es que lenguaje lo conozcas bien y te sirva para programar bien y rapido, que no tengas que tener 10 programadores en la empresa, uno para cada lenguaje si el lenguaje es un poco mas lento, prefiero invertir 100 dolares en mas memoria o aregar un server que agregar un lenguaje mas al cuento
Re: Alternativa correcta (socket daemon)
te sugiero que en modo debug logueees y despliegues por consola el resultado de esta funcion http://cl.php.net/manual/en/function.memory-get-usage.php
Re: Alternativa correcta (socket daemon)
On Fri, 2009-01-23 at 09:46 -0300, Asdtaker wrote: > On 1/22/09, Eduardo Silva wrote: > > Opinion personal: Si es un server que no tendra mucha concurrencia y > los > > tiempos de respuesta no son criticos, yo te recomendaria hacerlo en Python, > > de lo contrario en C. > A que viene esto? Las diferencias entre python y c no son abismantes > como para hacer tales recomendaciones. El hecho de que sea > interpretado, no es, por si mismo, sinónimo de lentitud. Rant: Tambien influye la RAM. Ademas, no podemos programar todo un sistema en algo interpretado (alguna vez existio JavaOS ...); imaginate que todos los applets de gnome sean en python o net ... el consumo de ram subiria al doble al menos. -- Aldrin Martoq http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: Alternativa correcta (socket daemon)
Juan Manuel Doren escribió: te sugiero que en modo debug logueees y despliegues por consola el resultado de esta funcion http://cl.php.net/manual/en/function.memory-get-usage.php buena idea lo implemte(estoy bien la salida en /var/log/message) y la memoria se incremente++, creo que por ahi va el tema voy a buscar la manera de tratar de liberarla (usando unset y no tengo variable globales)
Re: Alternativa correcta (socket daemon)
On Fri, 2009-01-23 at 10:52 -0300, Juan Manuel Doren wrote: > >anoche estube estudiando sus comentario (que los agrasco) y > > tratar de buscar una solucion aplique unas configuracion en el script > > (ademas toque el php.ini). Hoy para variar en la mañana se volvio a caer > > inesperadamente el script, nada en los log y ningun mensaje en la consola, > > ahora lo volvi a subir pero con el comando nohup para ver su salida (luego > > comento que pasa) > si tienes espacio en disco graba un log con todo lo que hace y un > flush() en cada escritura No, usas syslog: http://cl.php.net/syslog > si lo que quieres es hacer debug no uses nohup, abre el proceso en una > consola como cualquier programa, primero concentrate en que sea > estable y despues en demonizarlo Bueno, casi todas las recomendaciones asumen que algo esta mal hecho... > si no te puedes dar el lujo de que el proceso este abajo un rato > metelo en un loop > algo asi: > #while(true) do echo "prtieron"; date;./miscript.sh; free > >>error.log;date >>error.log;done urgh ... -- Aldrin Martoq http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: Alternativa correcta (socket daemon)
estas usando clases ??? On Fri, Jan 23, 2009 at 9:57 AM, Hector Salinas wrote: > Juan Manuel Doren escribió: > >> te sugiero que en modo debug logueees y despliegues por consola el >> resultado de esta funcion >> http://cl.php.net/manual/en/function.memory-get-usage.php >> >> buena idea lo implemte(estoy bien la salida en /var/log/message) > y la memoria se incremente++, creo que por ahi va el tema > voy a buscar la manera de tratar de liberarla (usando unset y no tengo > variable globales) > > -- Eduardo Silva http://edsiper.linuxchile.cl
Re: Alternativa correcta (socket daemon)
Eduardo Silva escribió: estas usando clases ??? no. ninguna clase. Además tengo todo bien cerrado al momento de consultar el DBMS y use sus correpondientes unset() On Fri, Jan 23, 2009 at 9:57 AM, Hector Salinas wrote: Juan Manuel Doren escribió: te sugiero que en modo debug logueees y despliegues por consola el resultado de esta funcion http://cl.php.net/manual/en/function.memory-get-usage.php buena idea lo implemte(estoy bien la salida en /var/log/message) y la memoria se incremente++, creo que por ahi va el tema voy a buscar la manera de tratar de liberarla (usando unset y no tengo variable globales)
Re: Alternativa correcta (socket daemon)
2009/1/23 Hector Salinas : > Eduardo Silva escribió: >> >> estas usando clases ??? >> > > no. ninguna clase. Además tengo todo > bien cerrado al momento de consultar el DBMS y use sus correpondientes > unset() ¿funciones que se llamen a si mismas? mysql_free_result() ? mysql_pconnect() ? ( para no tener que reconectar cada vez )
Re: Alternativa correcta (socket daemon)
Juan Manuel Doren escribió: 2009/1/23 Hector Salinas : Eduardo Silva escribió: estas usando clases ??? no. ninguna clase. Además tengo todo bien cerrado al momento de consultar el DBMS y use sus correpondientes unset() ¿funciones que se llamen a si mismas? no tengo recursividad mysql_free_result() ? sip lo uso mysql_pconnect() ? ( para no tener que reconectar cada vez ) no lo estoy usando, uso mysql_connect pero ahora las ultmas prueba que hice saque el codigo de conexion al DBMS y solo deje esto #!/usr/bin/php -q ".memory_get_usage(); socket_write($client, "A"); unset($client); unset($input); $contador++; } socket_close($sock); ?> y mirando la salida y escuando al cliente sale esto, la memoria siempre va en aumento. *** New client connected: 192.168.1.170 memoria usada -->40272 *** New client connected: 192.168.1.170 memoria usada -->40320 *** New client connected: 192.168.1.170 memoria usada -->40360 *** New client connected: 192.168.1.170 memoria usada -->40440 *** New client connected: 192.168.1.170 memoria usada -->40480
Re: Alternativa correcta (socket daemon)
Hector Salinas escribió:
> #!/usr/bin/php -q
> set_time_limit (0);
> $address = '192.168.1.235';
> $port = 5000;
> $sock = socket_create(AF_INET, SOCK_STREAM, 0);
> socket_set_option($sock, SOL_SOCKET, SO_REUSEADDR, SOL_TCP);
> socket_bind($sock, $address, $port) or die('error bind en la ip');
> socket_listen($sock);
> while (true)
> {
> $client = socket_accept($sock);
> socket_getpeername($client, $ip);
> $input = socket_read($client, 10);
> echo "\n***";
> echo "\nNew client connected: {$ip}";
> echo "\nmemoria usada -->".memory_get_usage();
> socket_write($client, "A");
socket_close($client); ?
> unset($input);
> $contador++;
> }
> socket_close($sock);
> ?>
--
Alvaro Herrerahttp://www.advogato.org/person/alvherre
"Industry suffers from the managerial dogma that for the sake of stability
and continuity, the company should be independent of the competence of
individual employees." (E. Dijkstra)
Re: Alternativa correcta (socket daemon)
Alvaro Herrera escribió: Hector Salinas escribió: #!/usr/bin/php -q ".memory_get_usage(); socket_write($client, "A"); socket_close($client); ? sorry si lo tenia (error de copy, paste) sigue pasando el mismo efecto de incrementar memoria ( con y sin socket_close($client); )
Re: Alternativa correcta (socket daemon)
estas cerrando el socket fuera de tu loop, lo cual te hara llegar al limite
del sistema para ese proceso: 1024 si es usuario normal.
On Fri, Jan 23, 2009 at 12:46 PM, Alvaro Herrera wrote:
> Hector Salinas escribió:
>
> > #!/usr/bin/php -q
> > > set_time_limit (0);
> > $address = '192.168.1.235';
> > $port = 5000;
> > $sock = socket_create(AF_INET, SOCK_STREAM, 0);
> > socket_set_option($sock, SOL_SOCKET, SO_REUSEADDR, SOL_TCP);
> > socket_bind($sock, $address, $port) or die('error bind en la ip');
> > socket_listen($sock);
> > while (true)
> > {
> > $client = socket_accept($sock);
> > socket_getpeername($client, $ip);
> > $input = socket_read($client, 10);
> > echo "\n***";
> > echo "\nNew client connected: {$ip}";
> > echo "\nmemoria usada -->".memory_get_usage();
> > socket_write($client, "A");
>
> socket_close($client); ?
>
> > unset($input);
> > $contador++;
> > }
> > socket_close($sock);
> > ?>
>
>
>
> --
> Alvaro Herrera
> http://www.advogato.org/person/alvherre
> "Industry suffers from the managerial dogma that for the sake of stability
> and continuity, the company should be independent of the competence of
> individual employees." (E. Dijkstra)
>
--
Eduardo Silva
http://edsiper.linuxchile.cl
Re: Alternativa correcta (socket daemon)
oh, error, no tu close fuera del loop esta bien, el problema es que no
cierras el socket cliente cuando terminas de utilizarlo
On Fri, Jan 23, 2009 at 12:56 PM, Eduardo Silva wrote:
> estas cerrando el socket fuera de tu loop, lo cual te hara llegar al limite
> del sistema para ese proceso: 1024 si es usuario normal.
>
>
> On Fri, Jan 23, 2009 at 12:46 PM, Alvaro Herrera
> wrote:
>
>> Hector Salinas escribió:
>>
>> > #!/usr/bin/php -q
>> > > > set_time_limit (0);
>> > $address = '192.168.1.235';
>> > $port = 5000;
>> > $sock = socket_create(AF_INET, SOCK_STREAM, 0);
>> > socket_set_option($sock, SOL_SOCKET, SO_REUSEADDR, SOL_TCP);
>> > socket_bind($sock, $address, $port) or die('error bind en la ip');
>> > socket_listen($sock);
>> > while (true)
>> > {
>> > $client = socket_accept($sock);
>> > socket_getpeername($client, $ip);
>> > $input = socket_read($client, 10);
>> > echo "\n***";
>> > echo "\nNew client connected: {$ip}";
>> > echo "\nmemoria usada -->".memory_get_usage();
>> > socket_write($client, "A");
>>
>> socket_close($client); ?
>>
>> > unset($input);
>> > $contador++;
>> > }
>> > socket_close($sock);
>> > ?>
>>
>>
>>
>> --
>> Alvaro Herrera
>> http://www.advogato.org/person/alvherre
>> "Industry suffers from the managerial dogma that for the sake of stability
>> and continuity, the company should be independent of the competence of
>> individual employees." (E. Dijkstra)
>>
>
>
>
> --
> Eduardo Silva
> http://edsiper.linuxchile.cl
>
--
Eduardo Silva
http://edsiper.linuxchile.cl
Re: Alternativa correcta (socket daemon)
> while (true)
> {
>$client = socket_accept($sock);
>socket_getpeername($client, $ip);
>$input = socket_read($client, 10);
>echo "\n***";
>echo "\nNew client connected: {$ip}";
>echo "\nmemoria usada -->".memory_get_usage();
>socket_write($client, "A");
>unset($client);
>unset($input);
>$contador++;
> }
> socket_close($sock);
hace años que no programo sockets pero ( y si estoy mal que alguien me corrija )
pero en dentro del loop no seria apropiado un
socket_close( $client ) justo antes del unset
de hecho los unset los sacaria, no los creo necesarios ya que
reutilizas la variable
Re: Alternativa correcta (socket daemon)
Hector Salinas escribió:
> #!/usr/bin/php -q
> set_time_limit (0);
> $address = '192.168.1.235';
> $port = 5000;
> $sock = socket_create(AF_INET, SOCK_STREAM, 0);
> socket_set_option($sock, SOL_SOCKET, SO_REUSEADDR, SOL_TCP);
> socket_bind($sock, $address, $port) or die('error bind en la ip');
> socket_listen($sock);
> while (true)
> {
> $client = socket_accept($sock);
> socket_getpeername($client, $ip);
> $input = socket_read($client, 10);
> echo "\n***";
> echo "\nNew client connected: {$ip}";
> echo "\nmemoria usada -->".memory_get_usage();
> socket_write($client, "A");
> unset($client);
> unset($input);
> $contador++;
> }
> socket_close($sock);
> ?>
Hmm, leyendo la pagina sobre variables en el manual de PHP te
recomendaria que pusieras las variables que son "locales" dentro de una
funcion. No queda para nada claro que la memoria se libere al hacer un
"unset". O sea, algo asi:
#!/usr/bin/php -q
".memory_get_usage();
}
socket_close($sock);
?>
--
Alvaro Herrera http://www.PlanetPostgreSQL.org/
"I think my standards have lowered enough that now I think 'good design'
is when the page doesn't irritate the living f*ck out of me." (JWZ)
Re: Alternativa correcta (socket daemon)
2009/1/23 Aldrin Martoq : > > Rant: Tambien influye la RAM. Ademas, no podemos programar todo un > sistema en algo interpretado (alguna vez existio JavaOS ...); imaginate > que todos los applets de gnome sean en python o net ... el consumo de Hey! que no quede la impresión de que hacer algo en Python es super costoso en memoria, tener muchos interpretes sí. Según las necesidades debes barajar y además, cuanto tiempo demoraría hacer algo en C v/s python? Eso es algo a tomar en consideración, además la mayoría de los módulos de Python están hecho en C :-) > ram subiria al doble al menos. > -- http://www.mgonzalez.cl/
Re: Alternativa correcta (socket daemon)
2009/1/23 Aldrin Martoq : > On Fri, 2009-01-23 at 09:46 -0300, Asdtaker wrote: >> On 1/22/09, Eduardo Silva wrote: >> > Opinion personal: Si es un server que no tendra mucha concurrencia y >> los >> > tiempos de respuesta no son criticos, yo te recomendaria hacerlo en Python, >> > de lo contrario en C. >> A que viene esto? Las diferencias entre python y c no son abismantes >> como para hacer tales recomendaciones. El hecho de que sea >> interpretado, no es, por si mismo, sinónimo de lentitud. > > Rant: Tambien influye la RAM. Ademas, no podemos programar todo un > sistema en algo interpretado (alguna vez existio JavaOS ...); imaginate > que todos los applets de gnome sean en python o net ... el consumo de > ram subiria al doble al menos. Otro buen ejemplo es Sugar[1][2], implementado todo en Python, AFAIK. Es lentísimo. Quizás en un laptop común y corriente funcione bien, pero en el limitado XO no. Posiblemente una de las no-muy-buenas ideas del proyecto OLPC. Pero quien sabe, quizás PyPy[3] sea el intérprete del futuro y podamos ser mas felices escribiando todo en Python... [1] http://wiki.laptop.org/go/Sugar [2] http://en.wikipedia.org/wiki/Sugar_(GUI) [3] http://codespeak.net/pypy/dist/pypy/doc/home.html -- Leo Soto M. http://blog.leosoto.com
Re: Alternativa correcta (socket daemon)
Alvaro Herrera escribió: Hector Salinas escribió: #!/usr/bin/php -q ".memory_get_usage(); socket_write($client, "A"); unset($client); unset($input); $contador++; } socket_close($sock); ?> Hmm, leyendo la pagina sobre variables en el manual de PHP te recomendaria que pusieras las variables que son "locales" dentro de una funcion. No queda para nada claro que la memoria se libere al hacer un "unset". O sea, algo asi: #!/usr/bin/php -q ".memory_get_usage(); } socket_close($sock); ?> ok, estube testieando este script y sigo con el drama del incremento de memory, creo debe ser al bug de las funciones socket*
Re: Alternativa correcta (socket daemon)
Hector Salinas escribió:
> Alvaro Herrera escribió:
> ok, estube testieando este script y sigo con el drama del
> incremento de memory, creo debe ser al bug de las funciones socket*
Otra idea: declara las variables como "static" dentro de la funcion.
>> #!/usr/bin/php -q
>> >
>> function do_client_stuff( ... )
>> {
static $client, $input, $ip;
>> $client = socket_accept($sock);
>> socket_getpeername($client, $ip);
>> $input = socket_read($client, 10);
>> echo "\n***";
>> echo "\nNew client connected: {$ip}";
>> socket_write($client, "A");
>> socket_close($client);
>> }
BTW a estas alturas, yo ya tengo más que claro que el problema es lo
penca que es PHP, y posiblemente tu programa funcionaría sin problemas
en un lenguaje bien implementado.
--
Alvaro Herrera http://www.flickr.com/photos/alvherre/
"When the proper man does nothing (wu-wei),
his thought is felt ten thousand miles." (Lao Tse)
Re: Alternativa correcta (socket daemon)
On Fri, 2009-01-23 at 15:15 -0300, Leo Soto M. wrote: > 2009/1/23 Aldrin Martoq : > > On Fri, 2009-01-23 at 09:46 -0300, Asdtaker wrote: > >> On 1/22/09, Eduardo Silva wrote: > >> > Opinion personal: Si es un server que no tendra mucha concurrencia y > >> los > >> > tiempos de respuesta no son criticos, yo te recomendaria hacerlo en > >> > Python, > >> > de lo contrario en C. > >> A que viene esto? Las diferencias entre python y c no son abismantes > >> como para hacer tales recomendaciones. El hecho de que sea > >> interpretado, no es, por si mismo, sinónimo de lentitud. > > > > Rant: Tambien influye la RAM. Ademas, no podemos programar todo un > > sistema en algo interpretado (alguna vez existio JavaOS ...); imaginate > > que todos los applets de gnome sean en python o net ... el consumo de > > ram subiria al doble al menos. > > Otro buen ejemplo es Sugar[1][2], implementado todo en Python, AFAIK. > Es lentísimo. Quizás en un laptop común y corriente funcione bien, > pero en el limitado XO no. Posiblemente una de las no-muy-buenas ideas > del proyecto OLPC. Hay que separar el concepto de la implementación. Si resultase lento, no implica que el concepto no haya sido una buena idea, sólo que la implementación o el diseño no fueron los adecuados, o que aún no se ha llegado al punto de optimizarlo. En palabras de Steve Yegge (un Googler), el libro del dragón tiene 30 años y es natural que los lenguajes estáticos resulten más rápidos. Pero una vez que se ha comenzado a aplicar optimizaciones similares en lenguajes dinámicos, va a cambiar. Y hay varios avances en esa línea, la mayoría impulsados por JavaScript, AJAX y la posibilidad de correrlo en dispositivos con pocas capacidades. Vale la pena leer "Dynamic Languages Strike Back" en: http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html Y el video se encuentra en http://www.youtube.com/watch?v=tz-Bb-D6teE (Y si, mencionan PyPy :-) -- Germán Póo-Caamaño http://www.calcifer.org/
Re: Alternativa correcta (socket daemon)
On Fri, 2009-01-23 at 11:53 -0300, Aldrin Martoq wrote: > On Fri, 2009-01-23 at 09:46 -0300, Asdtaker wrote: > > On 1/22/09, Eduardo Silva wrote: > > > Opinion personal: Si es un server que no tendra mucha concurrencia y > > los > > > tiempos de respuesta no son criticos, yo te recomendaria hacerlo en > > > Python, > > > de lo contrario en C. > > A que viene esto? Las diferencias entre python y c no son abismantes > > como para hacer tales recomendaciones. El hecho de que sea > > interpretado, no es, por si mismo, sinónimo de lentitud. > > Rant: Tambien influye la RAM. Ademas, no podemos programar todo un > sistema en algo interpretado (alguna vez existio JavaOS ...); imaginate > que todos los applets de gnome sean en python o net ... el consumo de > ram subiria al doble al menos. No creo. El costo de cargar las bibliotecas y el runtime lo tienes cuando cargas la primera aplicación. Luego, ya está en memoria. -- Germán Póo-Caamaño http://www.calcifer.org/
Re: Alternativa correcta (socket daemon)
Germán Póo-Caamaño escribió: > On Fri, 2009-01-23 at 11:53 -0300, Aldrin Martoq wrote: > > Rant: Tambien influye la RAM. Ademas, no podemos programar todo un > > sistema en algo interpretado (alguna vez existio JavaOS ...); imaginate > > que todos los applets de gnome sean en python o net ... el consumo de > > ram subiria al doble al menos. > > No creo. El costo de cargar las bibliotecas y el runtime lo tienes > cuando cargas la primera aplicación. Luego, ya está en memoria. Ese no es el punto; el punto es que las bibliotecas y el runtime son 10 veces más grandes. -- Alvaro Herrera Valdivia, Chile ICBM: S 39º 48' 55.3", W 73º 15' 24.7" "But static content is just dynamic content that isn't moving!" http://smylers.hates-software.com/2007/08/15/fe244d0c.html
Re: Alternativa correcta (socket daemon)
basado en tu codigo, lo he modificado y este codigo funciona correctamente sin incrementar el memory usage: memory usage: ".memory_get_usage(); unset($input); socket_close($client); } socket_close($sock); } test(); ?> fijate en unset el input, cerrar y cerrar el socket por cada bucle, de lo contrario te quedaras sin descriptores de archivos para recibir nuevos clientes, lo cual puede concluir en un exit. saludos -- Eduardo Silva http://edsiper.linuxchile.cl
Re: Alternativa correcta (socket daemon)
Aldrin Martoq escribió: [...] Rant: Tambien influye la RAM. Ademas, no podemos programar todo un sistema en algo interpretado (alguna vez existio JavaOS ...); http://www.jnode.org/ [...]
Re: Alternativa correcta (socket daemon)
On Fri, 2009-01-23 at 17:28 -0300, Rodrigo Ahumada wrote: > Aldrin Martoq escribió: > > Rant: Tambien influye la RAM. Ademas, no podemos programar todo un > > sistema en algo interpretado (alguna vez existio JavaOS ...); > http://www.jnode.org/ Vaya, esto fue refrescante... Claro que cuando comenzo a partir aparecio una excepcion con un tremendo stacktrace, me paralice unos milisegundos y luego pude reaccionar... http://aldrin.martoq.cl/img/Screenshot-JNode-stacktrace.png -- Aldrin Martoq http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: Alternativa correcta (socket daemon)
On Fri, 2009-01-23 at 16:08 -0300, Alvaro Herrera wrote: > BTW a estas alturas, yo ya tengo más que claro que el problema es lo > penca que es PHP, y posiblemente tu programa funcionaría sin problemas > en un lenguaje bien implementado. En general PHP ante cualquier error sigue no mas, lo mas que hace es chillar un Warning. Y ahora creo que es un milagro que esten funcionando sitios tan bien con PHP... o tal vez dejan de funcionar y nunca nos dimos cuenta? -- Aldrin Martoq http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: Alternativa correcta (socket daemon)
On Fri, 2009-01-23 at 15:47 -0300, Germán Póo-Caamaño wrote: > On Fri, 2009-01-23 at 11:53 -0300, Aldrin Martoq wrote: > > On Fri, 2009-01-23 at 09:46 -0300, Asdtaker wrote: > > > On 1/22/09, Eduardo Silva wrote: > > > > Opinion personal: Si es un server que no tendra mucha concurrencia y > > > los > > > > tiempos de respuesta no son criticos, yo te recomendaria hacerlo en > > > > Python, > > > > de lo contrario en C. > > > A que viene esto? Las diferencias entre python y c no son abismantes > > > como para hacer tales recomendaciones. El hecho de que sea > > > interpretado, no es, por si mismo, sinónimo de lentitud. > > Rant: Tambien influye la RAM. Ademas, no podemos programar todo un > > sistema en algo interpretado (alguna vez existio JavaOS ...); imaginate > > que todos los applets de gnome sean en python o net ... el consumo de > > ram subiria al doble al menos. > No creo. El costo de cargar las bibliotecas y el runtime lo tienes > cuando cargas la primera aplicación. Luego, ya está en memoria. Eso a nivel del sistema operativo, pero no a nivel de la maquina virtual... Manejar un "integer foo;" es muuucho mas caro. -- Aldrin Martoq http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: Alternativa correcta (socket daemon)
On Fri, 2009-01-23 at 15:59 -0300, Germán Póo-Caamaño wrote: > On Fri, 2009-01-23 at 15:15 -0300, Leo Soto M. wrote: > > 2009/1/23 Aldrin Martoq : > > > Rant: Tambien influye la RAM. Ademas, no podemos programar todo un > > > sistema en algo interpretado (alguna vez existio JavaOS ...); imaginate > > > que todos los applets de gnome sean en python o net ... el consumo de > > > ram subiria al doble al menos. > > Otro buen ejemplo es Sugar[1][2], implementado todo en Python, AFAIK. > > Es lentísimo. Quizás en un laptop común y corriente funcione bien, > > pero en el limitado XO no. Posiblemente una de las no-muy-buenas ideas > > del proyecto OLPC. > Hay que separar el concepto de la implementación. Si resultase lento, > no implica que el concepto no haya sido una buena idea, sólo que la > implementación o el diseño no fueron los adecuados, o que aún no se ha > llegado al punto de optimizarlo. > > En palabras de Steve Yegge (un Googler), el libro del dragón tiene 30 > años y es natural que los lenguajes estáticos resulten más rápidos. > Pero una vez que se ha comenzado a aplicar optimizaciones similares en > lenguajes dinámicos, va a cambiar. Y hay varios avances en esa línea, > la mayoría impulsados por JavaScript, AJAX y la posibilidad de correrlo > en dispositivos con pocas capacidades. > > Vale la pena leer "Dynamic Languages Strike Back" en: > http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html La charla esta en el contexto que lenguajes con tipos de datos dinamicos (Python) estan tomando fuerza versus los fuertemente tipados... basicamente la gente se aburrio de java ;) Pero la discusion de interpretado versus C es mas profunda a que "tiene que correr mas rapido". -- Aldrin Martoq http://aldrin.martoq.cl/videopodcast/ http://aldrin.martoq.cl/techblog/ signature.asc Description: This is a digitally signed message part
Re: Alternativa correcta (socket daemon)
On Fri, 2009-01-23 at 16:54 -0300, Alvaro Herrera wrote: > Germán Póo-Caamaño escribió: > > On Fri, 2009-01-23 at 11:53 -0300, Aldrin Martoq wrote: > > > > Rant: Tambien influye la RAM. Ademas, no podemos programar todo un > > > sistema en algo interpretado (alguna vez existio JavaOS ...); imaginate > > > que todos los applets de gnome sean en python o net ... el consumo de > > > ram subiria al doble al menos. > > > > No creo. El costo de cargar las bibliotecas y el runtime lo tienes > > cuando cargas la primera aplicación. Luego, ya está en memoria. > > Ese no es el punto; el punto es que las bibliotecas y el runtime son 10 > veces más grandes. No me pareció así, partiendo de el hecho que indicara "si todos los applets sean en Python o Net" y no "si cargas al menos un applet escrito en Python o Net". Por otro lado, si tienes el runtime en ejecución, cualquier siguiente aplicación (applet o no) cargará más rápido. En un Ubuntu cualquiera, siempre arranca el update-notifier (4.3MB), que si o sí cargará el runtime de Python (6.6MB). Y por otro lado, tienes el Applet de Network Manager (escrito en C) que son 4.3 MB. Con respecto al nm-applet, el runtime (y sus bibliotecas) solo es 1,2 veces más grande. Si le sumas el applet en cuestión, poco más de 2, pero (y este era el punto, creo yo), si cargas más applets en Python, estos no ocuparán más que el nm-applet. -- Germán Póo-Caamaño http://www.calcifer.org/
Re: Alternativa correcta (socket daemon)
On Fri, 2009-01-23 at 19:09 -0300, Aldrin Martoq wrote: > On Fri, 2009-01-23 at 15:47 -0300, Germán Póo-Caamaño wrote: > > On Fri, 2009-01-23 at 11:53 -0300, Aldrin Martoq wrote: > > > On Fri, 2009-01-23 at 09:46 -0300, Asdtaker wrote: > > > > On 1/22/09, Eduardo Silva wrote: > > > > > Opinion personal: Si es un server que no tendra mucha concurrencia y > > > > los > > > > > tiempos de respuesta no son criticos, yo te recomendaria hacerlo en > > > > > Python, > > > > > de lo contrario en C. > > > > A que viene esto? Las diferencias entre python y c no son abismantes > > > > como para hacer tales recomendaciones. El hecho de que sea > > > > interpretado, no es, por si mismo, sinónimo de lentitud. > > > Rant: Tambien influye la RAM. Ademas, no podemos programar todo un > > > sistema en algo interpretado (alguna vez existio JavaOS ...); imaginate > > > que todos los applets de gnome sean en python o net ... el consumo de > > > ram subiria al doble al menos. > > No creo. El costo de cargar las bibliotecas y el runtime lo tienes > > cuando cargas la primera aplicación. Luego, ya está en memoria. > > Eso a nivel del sistema operativo, pero no a nivel de la maquina > virtual... Manejar un "integer foo;" es muuucho mas caro. Eso se responde en el enlace que di. -- Germán Póo-Caamaño http://www.calcifer.org/
Re: Alternativa correcta (socket daemon)
hsalinas wrote: > Eduardo Silva escribió: > > Por tu comentario acerca de que "tu aplicacion deja de funcionar", > > quizas el error esta en "como" esta hecho el server y no en el > > lenguaje/interprete que fue utilizado para hacerlo. Como "deja de funcionar"? Termina la ejecucion, ...? > > Sobre tus preguntas: > > 1) No creo que hayas cometido un error en usar PHP, si bien yo no lo > > recomendaria para hacer un servidor, eso no significa que no pueda cumplir > > con el objetivo, si tu objetivo es concurrencia y escalabilidad... fue una > > mala eleccion y debio ser hecho en C. Mas o menos de acuerdo. Pero en general, si da con la carga (y no tiene otros problemas)... > > 2) Si deseas reescribirlo deberias evaluar: > > a) Tiempo que tienes para reescribirlo y que nivel de conocimiento > > tienes en cada lenguaje (no utilizaras el mismo tiempo para hacer un > > server en python que uno en C) Depende de como lo conectes a la red... si via algo como inetd/xinetd, puedes hacer algo en 3 o 5 lineas de shell. > estoy pensando en eso > > b) ¿ Tendra el server altos niveles de concurrencia ? 500 consultas > > por segundo ?? Tema "rendimiento". Y tambien considerar problemas de seguridad, ... > las hora pick que se utiliza el script son de las 7:00 a las 9:00 en > la mañana y en la tarde de 17:30 a 20:00 y dentro de esos rangos > consulta cada 5 a 7 segundo consulta la DBMS(que es el tiempo que se > demora un persona en pasar un toniquete) > > ¿eso es alto? Muy, muy, muy bajo. > > Opinion personal: Si es un server que no tendra mucha concurrencia y > > los tiempos de respuesta no son criticos, yo te recomendaria hacerlo en > > Python, de lo contrario en C. Si esta confortable con PHP, lo mas cercano puede ser Perl. > estoy mirando a monty python Que te diviertas! -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513
Re: Alternativa correcta (socket daemon)
Mario Gonzalez wrote: > 2009/1/23 Aldrin Martoq : > > Rant: Tambien influye la RAM. Ademas, no podemos programar todo un > > sistema en algo interpretado (alguna vez existio JavaOS ...); imaginate > > que todos los applets de gnome sean en python o net ... el consumo de > Hey! que no quede la impresión de que hacer algo en Python es super > costoso en memoria, tener muchos interpretes sÃ. Un "Hola, mundo!" en $LENGUAJE_INTERPETADO requiere tener el interprete en memoria, C no. > Según las necesidades debes barajar y además, cuanto tiempo demorarÃa > hacer algo en C v/s python? Eso es algo a tomar en consideración, > además la mayorÃa de los módulos de Python están hecho en C :-) El mismo inteprete tambien (salvo Jython, o IronPython). > > ram subiria al doble al menos. Lo que hoy es irrelevante. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513
Re: Alternativa correcta (socket daemon)
2009/1/23 Germán Póo-Caamaño : > On Fri, 2009-01-23 at 15:15 -0300, Leo Soto M. wrote: >> 2009/1/23 Aldrin Martoq : [...] >> > Rant: Tambien influye la RAM. Ademas, no podemos programar todo un >> > sistema en algo interpretado (alguna vez existio JavaOS ...); imaginate >> > que todos los applets de gnome sean en python o net ... el consumo de >> > ram subiria al doble al menos. >> >> Otro buen ejemplo es Sugar[1][2], implementado todo en Python, AFAIK. >> Es lentísimo. Quizás en un laptop común y corriente funcione bien, >> pero en el limitado XO no. Posiblemente una de las no-muy-buenas ideas >> del proyecto OLPC. > > Hay que separar el concepto de la implementación. Si resultase lento, > no implica que el concepto no haya sido una buena idea, sólo que la > implementación o el diseño no fueron los adecuados, o que aún no se ha > llegado al punto de optimizarlo. En el plano lógico, claro, tienes razón. Pero pragmáticamente uno termina juzgando los conceptos en base a las implementaciones (sino, ¿como diablos los juzgas en forma pragmática?) > En palabras de Steve Yegge (un Googler), el libro del dragón tiene 30 > años y es natural que los lenguajes estáticos resulten más rápidos. > Pero una vez que se ha comenzado a aplicar optimizaciones similares en > lenguajes dinámicos, va a cambiar. Y hay varios avances en esa línea, > la mayoría impulsados por JavaScript, AJAX y la posibilidad de correrlo > en dispositivos con pocas capacidades. > > Vale la pena leer "Dynamic Languages Strike Back" en: > http://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html +1! -- Leo Soto M. http://blog.leosoto.com
Re: Alternativa correcta (socket daemon)
Alvaro Herrera wrote: > Hector Salinas escribió: [...] > socket_close($client); ? Suena logico... se le acaban los descriptores de archivo, y se va de hocico. O se llena la memoria con la burocracia de conexiones y archivos, y paf. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513
Re: Alternativa correcta (socket daemon)
Hector Salinas wrote: [...] > ok, estube testieando este script y sigo con el drama del > incremento de memory, creo debe ser al bug de las funciones socket* No. Es muy comun un ataque de paranoia y comenzar a buscar culpables en tus herramientas. La inmensa mayoria de las veces _no_ son las herramientas, sino algo que hiciste mal tu (porque entendiste mal el manual, porque cometiste un error idiota que simplemente _no ves_ por mucho que leas tu programa, ...) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513
Re: Alternativa correcta (socket daemon)
Horst H. von Brand escribió: > Hector Salinas wrote: > > > ok, estube testieando este script y sigo con el drama del > > incremento de memory, creo debe ser al bug de las funciones socket* > > No. Es muy comun un ataque de paranoia y comenzar a buscar culpables en tus > herramientas. La inmensa mayoria de las veces _no_ son las herramientas, > sino algo que hiciste mal tu (porque entendiste mal el manual, porque > cometiste un error idiota que simplemente _no ves_ por mucho que leas tu > programa, ...) El programa ya fue publicado aquí ... ¿ves tú el error? Personalmente no tengo ningún problema en creer que hay un bug en PHP :-) -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ "Use it up, wear it out, make it do, or do without"
RE: Alternativa correcta (socket daemon)
Horst H. von Brand escribió: >El programa ya fue publicado aquí ... ¿ves tú el error? No veo el bendito error >Personalmente no tengo ningún problema en creer que hay un bug en PHP :-) Por que tanta mala a PHP -- Alvaro Herrera http://www.flickr.com/photos/alvherre/ "Use it up, wear it out, make it do, or do without" __ Information from ESET NOD32 Antivirus, version of virus signature database 3797 (20090124) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 3797 (20090124) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
Re: Alternativa correcta (socket daemon)
2009/1/25 Hector Salinas : > > Horst H. von Brand escribió: >>El programa ya fue publicado aquí ... ¿ves tú el error? > > No veo el bendito error > >>Personalmente no tengo ningún problema en creer que hay un bug en PHP :-) > > Por que tanta mala a PHP PHP lamentablemente como implementacion es mala. No hablamos de que la sintáxis del lenguaje es mala (lo es, aunque desde hace un tiempo se ha tratado de corregir las inconsistencias que ha tenido), sino de que tiene un manejo de memoria malo y de que tienes que rezarle a $DEIDAD para que una funcionalidad especial (como los sockets o el control de procesos) esté disponible de manera usable. Sin ir más lejos, hace unos días comentaba con alguien que desarrolla PHP (no "en el lenguaje", sino que hace el intérprete), y dijo que recién para PHP 5.3, se está arreglando el manejo de memoria para que no use "alloca()" (luego dijo algo de un stack que se llena rápido)... y una serie de detalles más que debido a mi alto nivel de grados alcohólicos (hey, es domingo en la mañana!!!) no comentaré. Yo personalmente, no puedo tenerle mala al lenguaje y lo defiendo cuando es posible y veo que las cosas no se están haciendo bien; gané mis lucas justas usándolo porque era la herramienta precisa para la tarea precisa; pero cuando las razones técnicas para no usarlo son de peso, no queda otra que reconocerlas. Y no por eso seré un fanboy. Saludos, -- Rodrigo Fuentealba http://www.thecodekeeper.net/
Re: Alternativa correcta (socket daemon)
creo haber publicado el codigo que funciona sin problemas: memory usage: ".memory_get_usage(); unset($input); socket_close($client); } socket_close($sock); } test(); ?> mantiene siempre su mismo consumo de memoria una vez que el cliente deja de ser atendido. salu2.- 2009/1/25 Rodrigo Fuentealba > 2009/1/25 Hector Salinas : > > > > Horst H. von Brand escribió: > >>El programa ya fue publicado aquí ... ¿ves tú el error? > > > > No veo el bendito error > > > >>Personalmente no tengo ningún problema en creer que hay un bug en PHP :-) > > > > Por que tanta mala a PHP > > PHP lamentablemente como implementacion es mala. No hablamos de que la > sintáxis del lenguaje es mala (lo es, aunque desde hace un tiempo se > ha tratado de corregir las inconsistencias que ha tenido), sino de que > tiene un manejo de memoria malo y de que tienes que rezarle a $DEIDAD > para que una funcionalidad especial (como los sockets o el control de > procesos) esté disponible de manera usable. > > Sin ir más lejos, hace unos días comentaba con alguien que desarrolla > PHP (no "en el lenguaje", sino que hace el intérprete), y dijo que > recién para PHP 5.3, se está arreglando el manejo de memoria para que > no use "alloca()" (luego dijo algo de un stack que se llena rápido)... > y una serie de detalles más que debido a mi alto nivel de grados > alcohólicos (hey, es domingo en la mañana!!!) no comentaré. > > Yo personalmente, no puedo tenerle mala al lenguaje y lo defiendo > cuando es posible y veo que las cosas no se están haciendo bien; gané > mis lucas justas usándolo porque era la herramienta precisa para la > tarea precisa; pero cuando las razones técnicas para no usarlo son de > peso, no queda otra que reconocerlas. Y no por eso seré un fanboy. > > Saludos, > > -- > Rodrigo Fuentealba > http://www.thecodekeeper.net/ > > -- Eduardo Silva http://edsiper.linuxchile.cl
Re: Alternativa correcta (socket daemon)
Hector Salinas escribió: > > Álvaro Herrera escribió: > >El programa ya fue publicado aquí ... ¿ves tú el error? > > No veo el bendito error Le preguntaba a Horst :-) > >Personalmente no tengo ningún problema en creer que hay un bug en PHP :-) > > Por que tanta mala a PHP Porque lo he visto por dentro. -- Alvaro Herrera Developer, http://www.PostgreSQL.org/ "Cada quien es cada cual y baja las escaleras como quiere" (JMSerrat)
Re: Alternativa correcta (socket daemon)
On Sun, Jan 25, 2009 at 3:49 AM, Hector Salinas wrote:
>
> Horst H. von Brand escribió:
>>El programa ya fue publicado aquí ... ¿ves tú el error?
>
> No veo el bendito error
>
>>Personalmente no tengo ningún problema en creer que hay un bug en PHP :-)
>
> Por que tanta mala a PHP
Porque es como el MySQL de los lenguajes de programación ;-)
[No mucho diseño detrás, pero al principio hacen lo que se tiene que
hacer y no se ven tal mal ("less is more", "worse is better" y todo
eso). Igual tarde o temprano la gente se da cuenta que para cosas
puntuales sirve pero no es un sistema cuerdo en general. Aparte que
mientras los autores más tratan de arreglarle las inconsistencias y
deficiencias, más se nota cuan fea está la cosa por debajo. Luego los
usuarios miran para el lado, encuentran un buen reemplazante (diseñado
como la gente, más coherente) y se olvidan del susodicho, excepto
cuando hay ocasiones de echar algo de bronca en los foros de
discusión]
--
Leo Soto M.
http://blog.leosoto.com
Re: Alternativa correcta (socket daemon)
Alvaro Herrera escribió: > No queda para nada claro que la memoria se libere al hacer un > "unset". No, la memoria no se libera al hacer unset() solo decrementa el contador de referencias, la memoria se libera "at script shutdown" y/o en versiones muy recientes (5.3.x) cuando "corre" el garbage collector. -- "We have art in order not to die of the truth" - Friedrich Nietzsche Cristian Rodríguez R. Software Developer Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
Re: Alternativa correcta (socket daemon)
Rodrigo Fuentealba escribió: > Sin ir más lejos, hace unos días comentaba con alguien que desarrolla > PHP (no "en el lenguaje", sino que hace el intérprete), Aqui estoy ! :P >porque era la herramienta precisa para la > tarea precisa; Exactamente, y es la herramienta precisa para la __web__ para el resto recomendaria una herramienta diferente si no se entiende como funciona en detalle la forma en que PHP libera memoria o controla procesos. -- "We have art in order not to die of the truth" - Friedrich Nietzsche Cristian Rodríguez R. Software Developer Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
Preguntas cuerdas [Was: Re: Alternativa correcta (socket daemon)]
Ricardo Utreras Estrella wrote: > Hector Salinas escribió: > > Hola Listeros : > > ... > > Ps: necesito una repuesta constructiva, antes de que me tiren a los > > Leones > ¿Ven como fomentan el miedo a realizar preguntas? (Al que le llegue) Es sano fomentar miedo a preguntar idioteces, y en general a hacernos perder el tiempo. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile 234 Fax: +56 32 2797513
