Actualizaciones, un retraso en el juego?

[elendriel]

Originally Posted by pescau

yo voto por b), que la actualización salga cuando esté bien; no cuando el calendario diga que tiene que salir

Por ejemplo, a mi me gusta la política de freebsd, por ejemplo en su calendario te dicen que día 10 de Noviembre de 2009 saldrá la beta 1, si no esta lo suficientemente pulida para que salga la beta 1, la retrasan, y así con cada versión, tienen un planning pero no estático, sino flexible.

Así que me parece bien las fechas orientativas.

[pescaupintau]

claro, algo así quise decir. Lo importante es que si se tiene que atrasar porque hay problemas, que se atrase el tiempo que sea necesario

[ArcticWolf]

Originally Posted by elendriel

Exacto, cuantos menos nodos debas pasar mejor, pero también depende de tu canuto de conexión(es decir, si debes pasar por 10 nodos a 100 Megabits que pasar por 10 nodos a 56Kb)

Eso, más saltearse el control de QoS que hacen los ISP's y hasta tu propio equipo. Los routers hacen QoS, quiéraslo o no, al darle mayor prioridad a los puertos 80 y 21, más los puertos de mail comunes (salvo que uses uno de esos donde se puede desactivar). La mayoría de los firewalls también tiene cierto tipo de QoS.

También depende la calidad de tu quipo. Algunos modems dropean paquetes cuando se ven bajo presión de tráfico.

Originally Posted by elendriel

Todo influye, pero hay problemas respecto la comunicación cliente-servidor, que dependerán de muchos factores, pero muchos de los factores por los que falla el juego son respecto el servidor, es decir, que estan en las manos de NGD corregirlos.

- Optimizando el código(haciendo que requiera enviar menos información).

- Mejorando el servidor(poniendo uno mayor)

- Consiguiendo un ancho de banda mayor(no sé que ancho manejará, pero posiblemente se pueda usar un canuto mayor).

Regnum usa mucho ancho de banda, como es debido. Suena doloroso, pero aquellos usuarios que tengan una conexión de 512 no deberían jugar (con eso también se liberaría una gran parte de la carga). Hay motivos técnicos por el cual no se puede comprimir el flujo del protocolo más de lo actual y por el que tampoco se puede reducir la comunicación.

Un mito es el de pensar que el ancho de banda del cliente al servidor afecta a un solo usuario. Por más concurrencia que tengas, hay un hilo (supongo que es multi-hilo) de ejecución que está trabado esperando datos. Claro, esto podría parecer aislado hasta que se toma en consideración la cantidad de hilos dormidos o esperando respuesta, en especial en situaciones de combate.

Aún así, no siempre la concurrencia resuelve todos los problemas. Hay tareas que se pueden colocar en un hilo propio, pero que invariablemente deben ejecutar procesos en forma lineal. Un Handshake es un ejemplo, pero también un broadcast a todos los clientes y procesos de verificación. Tampoco te olvides que pueden ocurrir locks prolongados en los recursos, y eso es muy difícil de detectar sin un profiling intensivo (lo cual también degrada la performance).

Otro problema que puede ocurrir son las fugas de memoria por no tener los destructores necesarios, y si además se usa una mezcla de assembler entonces se debe tener muchísimo cuidado con eso. Por ejemplo, si J2EE está bastante refinado en manejo de memoria y se sigue comiendo 2gb de ram como desayuno si se corre por tiempos prolongados... Es lógico, entonces, suponer que Regnum agote los recursos en poco tiempo después de tantas batallas y clientes conectados (clientes = programa). Hay que tener cuidado con eso.

Hasta aquí hay crecimiento lineal, es decir, más potencia es más desempeño. Pero el problema es que en los sistemas cliente-servidor también uno se está limitando por la norma del "viejo más chico y lento". Si la mayoría de los usuarios tiene una conexión mediocre, tarda en responder y además tienen pérdida de paquetes alta entonces es un problema que está fuera de tu alcance (o bien, requiere la refactorización del cliente casi por completo).

Claro, usemos UDP. ¡TCP trae muchos problemas de eficiencia! Verifica los paquetes, los ordena y pide que estén completos... ¡Para la posición y skills no se necesita eso! Para el chat sí necesitás TCP... Ah, pero el problema base de UDP es que el overhead que perdés por parte de la verificación en el protocolo lo tenés que añadir en tu aplicación para verificar los datos. Perder uno o dos paquetes de cada diez está bien, pero cuando hay diferencias grandes entre los datos y una pérdida alta entonces el servidor tiene que verificar dichos datos. Supongo que parte del problema del posicionamiento viene de ahí y no del código en sí mismo. Alta latencia sumado a una velocidad de respuesta pobre genera los saltos y cuelgues en el movimiento.

Por lo que más velocidad, memoria e hilos de ejecución no va a solventar mucho.

¡Optimicen! Pero el problema con ello es que la optimización prematura trae como primer problema un algoritmo que a la larga es ineficiente. Hay que buscar dónde ocurre el cuello de botella y eliminarlo una vez que existe, pero primero debe funcionar toda la implementación. Si hay un bug, se optimiza, se resuelve el bug, se optimiza y luego se vuelve a parchear lo más seguro es que termines con el doble de bugs y un código difícil de entender. Por eso se refactoriza a menudo, porque es un ancla en el desarrollo.

¿Cómo implementar lo que dije? No sé, todavía no soy ni un décimo de profesional y tampoco tengo mucha experiencia. Además, el modelo de juego online que eligieron exige mejoras constantes y actualizaciones variadas, así que hace más complejo todo...

Yo tiraría todo al tacho y haría un asteroids online. Al menos no tengo que tolerar a nadie en balance.

Y voto por la opción de que salga cuando esté estable. Deb... Eh, Regnum ya tiene muchísimas cosas y puede vivir tranquilo con lo que está por un largo tiempo. Queda mucho para que se agote el tema de las invasiones (en fin, un Capture The Flag hiperdimensionado), así que pequeñas actualizaciones funcionales vienen bien*, para luego liberar algo más grande y estable.

Sin embargo, todos sabemos cómo es eso de liberar cuando está listo.

*Liberar rápido pocos buenos cambios mantiene la moral alta... Aunque sabemos que las comunidades online son como la gata flora. No a todos le va a gustar lo mismo...

[takola]

Sin ningun animo de defender las formas del creador del thread, cualquier comparacion con el modo de desarrollo de UNIX no tiene sentido Xeph.

Primero, esta KISS, Keep It Simple Stupid! Un programa hace una cosa y lo hace bien, y hasta que sea asi no se desarrollan mas features. En RO se añaden mas y mas y mas features sin arreglar bugs, por lo que de KISS nada de nada.

Por otro, esta la proteccion por ofuscacion (en cuanto a informacion), tipico en NGD, no tan habitual en entornos UNIX. Junto a ellos iria el tratamiento de bugs y su resolucion, un chiste aca, todo lo contrario en UNIX.

Por otro, en UNIX nada entra en produccion hasta que las cosas esten terminadas, testeadas como es debido y bien maduradas. en Regnum todo lo contrario.

El soporte de los sistemas comerciales UNIX suele ser increible, el soporte de NGD hacia sus clientes brilla por su ausencia en la mayoria de los casos.

Y todo eso sin ver el codigo, que si lo viesemos estoy seguro de que encontrariamos muchisimas mas diferencias radicales entre el tipico desarrollo unix y el de regnum.

Por otro, lo del cliente madurado da la risa. El cliente debe tener bastante memory leaks, no es normal que me consuma 2Gb enteros y que empieze a swapear tras horas jugando. Es clarisima sintoma de memory leaks.

Tampoco es normal que el server envie informacion redundante al cliente porque faltan datos. Cuando el server informa de un enemigo avistado manda info de nombre,reino,clan etc etc. Pues bien, esa informacion te puede llegar tres o cuatro veces seguidas porque falta alguno de los datos. Y no hablo de udp, hablo del stream tcp por lo no es que se haya perdido un datagrama por el camino. Asi era hace no mucho tiempo y no creo que haya cambiado mucho.

Tampoco es normal el rollback de code que parece haber en regnum. Obviamente no se puede confirmar sin ver el code pero tanto bug que vuelve tras X tiempo solucionado suena a eso. O no hay un sistema de control de versiones decente o algo raro pasa.

Tampoco es normal tener un pseudobugtraq en la web principal y tener bugs sin confirmar ni cerrar ni nada durante años. Ahora mismo estan cerrados pero los bugs reportados cuando existia el boton de reporte en el cliente estaban abiertos y sin tocarlos hasta no hace muchos meses, al menos en ese bugtraq. Quiero creer que habra otro sistema para ello, pero no se yo.

Tampoco es normal meter en produccion una feature de cambio de nombres en el foro que no checkee si existen dichos nombres en la db!

Tampoco es normal tener a clientes sin ningun tipo de respuesta durante dias, semanas o meses. Si esto fuera una tienda, vas a preguntar al del mostrador por una reclamacion y no te responde en meses que pensariais?

En fin, podria seguir pero ahi lo dejo. Y tal como dije otras veces, lo de que son pocos no sirve como excusa eternamente.

Saludos

[elendriel]

Solo decir, que estoy completamente de acuerdo con la argumentación expuesta por Takola, y que es inmejorable desde mi punto de vista.

[ArcticWolf]

Originally Posted by takola

Sin ningun animo de defender las formas del creador del thread, cualquier comparacion con el modo de desarrollo de UNIX no tiene sentido Xeph.

Primero, esta KISS, Keep It Simple Stupid! Un programa hace una cosa y lo hace bien, y hasta que sea asi no se desarrollan mas features. En RO se añaden mas y mas y mas features sin arreglar bugs, por lo que de KISS nada de nada.

Entendiste mal, tal vez yo no lo dejé claro. Lo que dije es que si se siguiera el Unix way entonces el camino lógico es arreglar los errores primero y luego optimizar. Esa fue mi primer respuesta...

No se puede optimizar en el vuelo el cliente o el servidor, y eso a menudo trae problemas con los esquemas de programación ágil. Un producto que se desarrolla al mismo tiempo que se usa se vuelve difícil de mantener si también se optimiza con cada release.

Si leíste los links entonces entenderías que la manera Unix nos dejó una enseñanza fundamental: "primero hacerlo andar, luego hacerlo bien y por último optimizarlo". Regnum está por la segunda etapa.

Mantengo mi opinión. El juego "anda", ahora tocaría hacerlo andar bien. ¿Cuándo dije que se guiaban por eso? Yo dije que se guiaban por la programación ágil.

Originally Posted by takola

Por otro, esta la proteccion por ofuscacion (en cuanto a informacion), tipico en NGD, no tan habitual en entornos UNIX. Junto a ellos iria el tratamiento de bugs y su resolucion, un chiste aca, todo lo contrario en UNIX.

Por otro, en UNIX nada entra en produccion hasta que las cosas esten terminadas, testeadas como es debido y bien maduradas. en Regnum todo lo contrario.

No concuerdo. En los sistemas Unix lo que se da a conocer generalmente de una aplicación es su modo de uso y configuración, pero no siempre el funcionamiento interno... Eso es de los sistemas GNU. POSIX define un comportamiento.

Los sistemas Unix requieren que algo esté estable para mandarlo a producción porque no son un juguete. Aclaré en mi anterior post que ese debería ser el modo (para mí) a adoptar.

Originally Posted by takola

El soporte de los sistemas comerciales UNIX suele ser increible, el soporte de NGD hacia sus clientes brilla por su ausencia en la mayoria de los casos.

Concuerdo.

Originally Posted by takola

Y todo eso sin ver el codigo, que si lo viesemos estoy seguro de que encontrariamos muchisimas mas diferencias radicales entre el tipico desarrollo unix y el de regnum.

Porque no se siguió el mismo modelo, lo cual es lógico.

Originally Posted by takola

Por otro, lo del cliente madurado da la risa. El cliente debe tener bastante memory leaks, no es normal que me consuma 2Gb enteros y que empieze a swapear tras horas jugando. Es clarisima sintoma de memory leaks.

Sí, y lo dije... Pero no me queda claro de dónde sacás lo de cliente maduro, porque creo que no lo mencioné en ninguna parte. Para mí esto es resultado de seis años de parcheo indiscriminado (típico de los MMORPG's).

Originally Posted by takola

Tampoco es normal que el server envie informacion redundante al cliente porque faltan datos. Cuando el server informa de un enemigo avistado manda info de nombre,reino,clan etc etc. Pues bien, esa informacion te puede llegar tres o cuatro veces seguidas porque falta alguno de los datos. Y no hablo de udp, hablo del stream tcp por lo no es que se haya perdido un datagrama por el camino. Asi era hace no mucho tiempo y no creo que haya cambiado mucho.

Creo que sigue parecido, aunque hubo un par de cambios. No tengo wireshark instalado ahora. Ese es uno de los casos donde deberían refactorizar, pero te comento que no es tan simple como suena. Hacer una transferencia de datos no es tan trivial, y habrán motivos para no cambiarlo ahora.

Originally Posted by takola

Tampoco es normal el rollback de code que parece haber en regnum. Obviamente no se puede confirmar sin ver el code pero tanto bug que vuelve tras X tiempo solucionado suena a eso. O no hay un sistema de control de versiones decente o algo raro pasa.

Ese "algo raro" creo que se debe más a que la mezcla de lua, c, c++ y assembler es un cóctel explosivo y muy fácil de romper... No a un rollback específico (no lo puedo confirmar sin el código). Estamos en la misma.

Originally Posted by takola

Tampoco es normal tener un pseudobugtraq en la web principal y tener bugs sin confirmar ni cerrar ni nada durante años. Ahora mismo estan cerrados pero los bugs reportados cuando existia el boton de reporte en el cliente estaban abiertos y sin tocarlos hasta no hace muchos meses, al menos en ese bugtraq. Quiero creer que habra otro sistema para ello, pero no se yo.

Yo no le daría pelota, al menos porque ese tracker era un despelote para los usuarios... No me quiero imaginar para los administradores. Prefiero un sistema de tickets como SimpleTicket (aunque esté en Ruby), que sea abierto al público para ver los bugs disponibles y milestones.

Originally Posted by takola

Tampoco es normal meter en produccion una feature de cambio de nombres en el foro que no checkee si existen dichos nombres en la db!

Tampoco es normal tener a clientes sin ningun tipo de respuesta durante dias, semanas o meses. Si esto fuera una tienda, vas a preguntar al del mostrador por una reclamacion y no te responde en meses que pensariais?

En fin, podria seguir pero ahi lo dejo. Y tal como dije otras veces, lo de que son pocos no sirve como excusa eternamente.

Saludos

El error está más por el lado de Jellsoft por hacer el login case-insensitive. Igualmente, ya estás hilando fino.

Con el tema de soporte estoy plenamente de acuerdo.

[nicolas_11]

papa , ensima que el juego es gratis te quejas ? :S

el chabon sabe mas de programacion que vos asique no le discutas nada.

bye ^^

[ArcticWolf]

Originally Posted by nicolas_11

papa , ensima que el juego es gratis te quejas ? :S

el chabon sabe mas de programacion que vos asique no le discutas nada.

bye ^^

Que sea gratis no tiene nada que ver, pero si va a criticar es mejor que lo haga de una forma constructiva.

[takola]

Originally Posted by nicolas_11

papa , ensima que el juego es gratis te quejas ? :S

el chabon sabe mas de programacion que vos asique no le discutas nada.

bye ^^

No tienes ni idea de lo que se o dejo de saber de programacion asi que callate mejor. Ahora leo y respondo si toca el post de Xeph

[ArcticWolf]

Originally Posted by takola

No tienes ni idea de lo que se o dejo de saber de programacion asi que callate mejor. Ahora leo y respondo si toca el post de Xeph

Creo que se refería al primer post. De vos no dudo que sabés de informática. Y mejor la corto acá porque no quiero armar un flame.