× PortadaNoticiasTrabajoColaboraciónEnlacesForosIRCFormaciónNosotros
Stratos: Developer's Meeting Point

Welcome to Stratos!

Acceder

Foros





Responder #15 por Capiflash
« 05 de Agosto de 2007, 11:44:09 pm »
Puedes por ejemplo tener un programa "corriendo" en el servidor , revisando la finalizacion de construcciones , la llegada de ataques y demas , o bien , puedes aprovechar las conexiones de los jugadores al entrar , para hacer todo eso "pendiente".

En este hilo se hablo de algo relacionado con este tema  , lo rescato por si ayuda a alguien

http://www.stratos-ad.com/forums3/viewtopic.php?t=5732&highlight=
Responder #16 por Tei
« 06 de Agosto de 2007, 12:52:05 pm »
Una forma seria programar una cola de acciones programadas, el servidor en cada frame no consume toda la cola, solo los eventos "caducados", y en orden cronologico.  Realizado asi, te da igual si entre ejecucion y ejecucin ha pasado un segundo, o dos meses.
El problema es que si han pasado muchas horas desde que se conecto un jugador, pues a lo mejor en lugar de consumir 30 eventos, tiene que consumir 3000. Y es mucho mas lento. La velocidad de ejecucion seria irregular, dependiendo de si eres el primero de la maana, por ejemplo, o eres el segundo (si eres el segundo te va instantaneo).

Asi que parece que es interesante tener una aplicacion corriendo todo el tiempo, que invoque estos frames del servidor. Ademas esta tarea podria realizar labores de mantenimiento.  Suponte que tienes una tabla de precios de productos. Podrias actualizar esta tabla cada 3 horas. O podrias regenerrar los ficheros del mapa como ficheros estaticos. De este modo cuando alguien los descargue, se descargara ficheros estaticos, lo que siempre es interesante.  Enfin, que tener un servidor o tarea corriendo te puede servir para que todo funcione mucho mejor.

No he escrito nada de este estilo. Asi que tampoco me hagas mucho caso.

nota: Si te da por invocar una pagina del servidor desde cron. Estilo wget http://localhost/game/serverframe.php?do=rulea. Ten cuidado y ponlo con limitacion de intentos. "wget -t 1 http://localhost/game/serverframe.php?do=rulea". Sino wget cuando vea que hay un problema,lo hara mas grave pidiendo la pagina una y otra vez hasta que el servidor no tenga CPU suficiente..
Responder #17 por waveland
« 08 de Agosto de 2007, 02:32:25 am »
Capiflash, interesante el hilo que posteaste.

Aado duda: que creis mejor, procesar las solicitudes pendientes de la base de datos mediante scripts PHP o bien mediante los cron jobs (primera vez que lo escucho pero supongo que son algo as como tareas programadas, verdad?), o tal vez mediante ambos. La duda me surge porque me da la impresin de que, si se almacenan muchas solicitudes, se puede saturar el servidor? es decir, sabis donde puede estar el lmite mas o menos?
Responder #18 por jazcks
« 08 de Agosto de 2007, 08:20:59 am »
creo que el lmite depende de cmo lo implemente cada uno.
Si las solicitudes estn en la base de datos, el cron job puede recoger varias de esas solicitudes cada X tiempo, segn el orden en que se grabaron y ejecutarlas.
Si lo programas cada 24horas seguramente tendr muchas ms que hacer que si el job corre cada 1h por ejemplo.
Es decir, no creo que se sature el servidor, las bases de datos estn hechas para eso, entre otras cosas para almacenar grandes cantidades.
Responder #19 por Tei
« 08 de Agosto de 2007, 09:28:43 am »
Cita de: "waveland"
Capiflash, interesante el hilo que posteaste.

Aado duda: que creis mejor, procesar las solicitudes pendientes de la base de datos mediante scripts PHP o bien mediante los cron jobs (primera vez que lo escucho pero supongo que son algo as como tareas programadas, verdad?), o tal vez mediante ambos. La duda me surge porque me da la impresin de que, si se almacenan muchas solicitudes, se puede saturar el servidor? es decir, sabis donde puede estar el lmite mas o menos?


cron es un programador de tareas, puedes programarle que ejecute lo que sea con la periodicidad que quieras. Por ejemplo cada viernes, o cada 15 minutos.

osea, es una opcion para hacer lo mismo:
 - o usas un demonio
 - o ejecutas una tarea con una periodicidad X.

El demonio puede ser mas delicado: No te interesa que haya leaks. Seria un desastre que hubiera un bucle infinito. Y tienes que disponer de un modo que si el demonio se muere, se relance. Y deberia ejecutarse al reiniciar el servidor, que se puede resetear solo por razones hardware.

con cron podrias ejecutar una aplicacion php de linea de comandos, o podrias invocar una pagina publica. lo de wget es invocando una pagina publica.

para un juego web hacer labores auxiliares en php tiene la ventaja de que reutilizas toda las librerias de la aplicacion. Sino se haria en Perl o algo asi.

Windows tambien tiene un servicio de ejecucion programada. Y si tienes contratado un hosting barato podria usarse para que tu ordenador invocara una pagina del juego web cada 30 minutos, corriendo asi los frames del servidor.  Y evitando asi la necesidad de un servidor dedicado.
Aunque si se quiere hacer algo serio yo apostaria por PHP5 y MySQL4. Y a lo mejor un hosting barato no te da mas que PHP4 y MySQL3.
Responder #20 por Kr0n
« 08 de Agosto de 2007, 09:50:41 am »
En general, hacer un daemon no es mucho ms complicado, slo que tienes que hacerlo "mejor" porque va a estar siempre corriendo, y deberas pues tener cierto control sobre si muere (que mande un mensaje o seal cuando muera), logs que genera, etc. Digamos que en comparacin con un script auxiliar en cron, el daemon necesita ms "envoltorio" alrededor de la misma funcionalidad para controlar ese tipo de cosas.

Hay situaciones en las que un daemon es 100% imprescindible. En el caso de un juego web, no creo que sea tan imprescindible. Pero aqu tambin juega en tu contra el tema servidor. O tienes servidor propio (o virtualizado), u olvdate de daemon porque te tendrs que conformar con un script ejecutndose en cron.

Y como ya han dicho, si tu aplicacin est en PHP, una gran ventaja que tiene hacer el script auxiliar correspondiente en PHP es que puedes reaprovechar toda la funcionalidad de las capas de servicios y de dominio que tengas en tu aplicacin/juego. Y eso es una gran baza porque adems de ahorrarte tiempo, te aseguras que la arquitectura de tu software se respeta. Sino, pues eliges el lenguaje que mejor te venga, no tiene porqu ser Perl: Python, Shell script (si hablamos de tareas auxiliares de mover/copiar archivos, etc) o incluso una solucin compilada en C/C++ (por motivos de velocidad, aunque el cuello de botella lo suele tener la BD, no el script)
Responder #21 por Vicente
« 08 de Agosto de 2007, 10:30:50 am »
Cita de: "Kr0n"
Sino, pues eliges el lenguaje que mejor te venga, no tiene porqu ser Perl: Python, Shell script (si hablamos de tareas auxiliares de mover/copiar archivos, etc) o incluso una solucin compilada en C/C++ (por motivos de velocidad, aunque el cuello de botella lo suele tener la BD, no el script)


Yo no tengo mucha idea de juegos web, pero para que el cuello de botella est en la BD la tienes que estar dando muchsima caa...

Un saludo!

Vicente
Responder #22 por Kr0n
« 08 de Agosto de 2007, 11:02:36 am »
Si, la verdad es que tena ms en mente una aplicacin web con mucha carga (estilo flickr, meneame, etc.) donde la escalabilidad tiene que andar muy afinada.

Al final todo depende de la carga que le metas al juego o aplicacin, claro.







Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.