Bueno, son un par de cosas que encontre mirando el codigo/se me ocurrieron mientras programaba.
1_En el sub UseInvItem del server, cuando manda el paquete para actualizar el inventario del cliente, note que actualizaba todo el inventario independientemente del slot que se haya usado. Esto explica el lag que causa tomar pociones, tirar flechas, talar o cualquier actividad similar. Para comprobarlo le agregue un server un contador de kbs enviados y recibidos x segundo, le pedi a 5 amigos que se logearan con unos pjs que tenian 10k de pociones cada 1 y que tomaran lo mas rapido posible todos a la vez. EL resultado fue entre 15 Y 20 kb de upstream del server consumidos, con solo 5 users...
En cambio, cuando puse especificamente en cada CASE del select que slot deberia ser actualizado(ejemplo, pociones, solo el slot de pociones, arco, ninguno ya que no cambia nada) no logro superar los 2.5kb.
2_Reemplace los mensajes de texto fijos que el servidor envia al cliente con "||blah blah" & fonttype... por codigos numericos, que se envian con un prefijo (por ejemplo use "!") y que el cliente, mediante un archivo init nuevo, cargado en un array, traduce al mensaje que es. Esto ayuda por el simple echo de que mandar "!" y un numero de maximo 3 digitos pesa menos que 2 oraciones enteras.
Bueno habia un par de cosas mas pero la verdad es que hace 2 semanas que me estoy acostando a eso de las 10 de la maana y la verdad en este momento no me acuerdo, cualquier cosa maana lo posteo
PD:Hice que el cliente pesara 130kb sacandole las imagenes que estan puestas fuera de run time (estan repetidas, las carga =) y haciendole UPX.
Saludos y posteen que me interesa su opinion.
Gracias, fer.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
es buena la idea de los slots, existen otras cosas tambien para reduccion de lag que aver si me acuerdo de alguna.
Sobre los mensajes nose si viste las screens de ao-mistico, nosotros hicimos eso con gran parte de los mensajes, como estas perdiendo energia que se ve con unas hermosas luces al lado de hambre y sed junto con en veneno entre otros, tambien con otros como "estas demaciado lejos para comerciar" o "estas muerto, no puedes comunicarte con el mundo de los vivos" que fueron pasados al cliente.
de la interface te dejo este link como para que veas como queda, que ademas de sacar bruto cartel tambien queda mejor a la estetica.
despues lo pongo por que no responde el foro de alkon.
otras ideas para reducir el lag, es pasar las charfile a base de datos, nosotros lo hicimos de manera precaria a access cuando tendriamos que hacerlo sql y con un contador medimos los tics y es la relacion de 1000 tics en archivo.chr a 100 tics en db te pego el log.
19/01/2004 13:09:38 Ticks en SaveUserDB - 100
19/01/2004 13:09:51 Ticks en SaveUserDB - 40
19/01/2004 13:10:06 Ticks en SaveUserDB - 40
19/01/2004 13:13:12 Ticks en en SaveUser - 1061
19/01/2004 13:13:25 Ticks en en SaveUser - 1262
19/01/2004 13:13:42 Ticks en en SaveUser - 1292
otra cosa tambien puede ser el envio de mensajes por objetos, haciendo que los detalles de los objetos puedan estar en el cliente, para ser mostrados, no para calcular golpe y eso, ya que lo hace el server, pero el problema con esto es que tendria que estar en db todos los objetos, por que sino tardaria mucho en abrir el cliente tanto como lo hacia la version 0.9.9c y posteriores.
y bueno, no se me esta ocurriendo que mas.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Lo de los mensajes lo tengo echo con todos, y funca muy bien. Es un archivo de texto, como este:
[INIT]
Mensajes=253
[MENSAJES]
MENSAJE1=No pods tener mas objetos.
MENSAJE2=No tienes mas espacio en el banco!!
MENSAJE3=No ves nada interesante.
MENSAJE4=Has prendido la fogata.
MENSAJE5=No has podido hacer fuego.
MENSAJE6=%%%%POR FAVOR ESPERE, INICIANDO WORLDSAVE%%%%
MENSAJE7=%%%%WORLDSAVE DONE%%%%
Luego pasado a binario con un boton nuevo en el encoder. Es facil de hacer, quizas te tome un rato pasar los mensajes al txt pero despues es una webada, pero realmente ayuda.
y lo otro la verdad no se casi nada de DBs, pero a mi entender eso reduciria el tiempo de carga de las fichas, que seria mas bien un tema de maquina mas bien y no de conexion (corrijanme si me equivoco, no estoy seguro realmente). De todas maneras todo viene bien.
PD: te olvidaste el link =P
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Me parece que con respecto al protocolo de AO1 es muy deficiente y algunas de las cosas que proponen mejoraria muchisimo el ancho de banda.
Tiempo atras yo habia rediseñado casi todo el protocolo server-cliente (lamentablemente lo perdi con una formateada).
Los cambios que le hice eran los siguiente:
Primero ningun mensaje en forma de texto era ENVIADO por el servido, sino que el cliente tenia una lista (mensajes.txt) con TODOS los mensajes, que de los cuales escojia el que necesitaba y el server lo unico que tenia que enviar era dos bytes, uno undicaba que el cliente tenia que mostrar un mensaje y el otro el indice del mensaje. En al caso de mensajes que contenian valores, por ejemplo "La criatura te a pegado por 10." donde esta el numero se lo reemplaza por un "%d" al mejor estilo printf. El server tendria que sumar unos bytes adicional, Comando-IndiceMSJ-Valores.
Ventajas: Ahorro significativo de ancho de banda, y cliente de AO traducible a otros idiomas (Como paso con AO2 isometrico).
Segundo el protocolo ya no enviaba strings sino que enviaba un byte (OLOGIN = 0, AT = 1, etc) que indicaba el cada comando. En el caso del comando "M" lo desplege en cuatro MN = 2, MS = 3, ME = 4, MO = 5. Todos los comandos se tranformarian en un gran ENUM que ayudaria mucho al server. Ya que la gran cantidad de IF y SELECT CASE con Left y Right quedan deprolijos y consumen micro de forma inecesaria. Dura tarea pero creo que aliviana mucho el lag.
Nunca lo pude probar con muchos users y creo que voy a volver a mis andansas.
quisiera saber si alguien ya puso manos en la masa?
Una preguntita sobre el CVS, puede ser que tenga pass el anonimo, si tiene pasenlo.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
En cuanto a tu pregunta, si, esto es algo que se viene planeando (deseando, pidiendo, reclamando, implorando, etc) desde ya hace varios años. Además, hasta hace mese y medio (casi dos) el codigo que habia en el CVS tenia parte de tales cambios ya realizados, pero por motivos "administrativos" se hizo un rollback de todo.
Ahora mismo están planeados para las siguientes versiones, a realizarse e implementarse en forma gradual.
El CVS anonimo no tiene pass. El truco está en que solo podes entrar usando "pserver". SSH es solo para developers; si intentas entrar por SSH como anonimo no vas a poder (te pide la pass que vos pedís). Para mas informacion, metete en la seccion "CVS" del proyecto en SF:
Como bien dijeron acá mis compañeros, esto es algo que se plantió muchas veces y hasta se implementó, pero como mencionó Alejo por problemas "administrativos" se debió hacer rollback. De todas formas, Imperium AO sí está usando el protocolo binario mencionado que yo había programado hace cerca de un año, y ha demostrado dar excelentes resultados (cayó el consumo de ancho de banda a la mitad).
El protocolo binario entra en la 11.6 reduciendo considerablemente el peso de muchos mensajes (en esta ocasión el diseño presenta algunas diferencias respecto a como lo hice el año pasado, básicamente para hacerlo más flexible y limpio, recordemos tuve bastante tiempo más para pensarlo y pulir el diseño), y en las versiones subsiguietnes 11.7 y 11.8 entran modificaciones del mismo (nuevos paquetes para subdividir a otros, unificación de paquetes que no se usan separados, etc.).
El no envio de mensajes de consola (salvo chats o cosas similares) es también algo que se va a realziar en estas versiones.
De más está decir que si te interesa colaborar con esto este es el lugar indicado para hacerlo pues en cuanto se comiencen los trabajos en la 11.6 todo esto estará siemrpe actualizado en el CVS.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Al parecer ya esta todo listo como para provocar un quiebre en el protocolo. Es posible poder ver un bosquejo de como va a ser implementado o que tienen en mente para que el grupo lo pueda analisar.
Otro pequeño truquito que me han comentado que se suele usar y que es denominado "reply" (creo). Consiste en que los mismos PJ se comuniquen enviando info de su propio estado (por ejemplo, pos X, Y, cosas equipadas, es fantasma, etc) para aminorar la carga en el server. Esto habria que analizarlo con detalle, ya que podria traer mas problemas de los que ya hay. Pero si funciona se podria generar una pequeña red P2P de datos "inocentes", que liberaria al server de esa carga para atender asuntos mas importantes.
Me voy a mantener al tanto de los avances.
Ya pude acceder al CVS :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
mm ese sistema lo tenia aplicado a mi mmorpg personal pero.. nunca lo testie con muchos users.. jejej =P
y a decir verdad, una gran parte de los usuarios de AO se conectan con dial up todavia.. o con maquinas no apropiadas para hacer de host.. asi que no se si sera buena idea ponerlo.. anque en teoria es bueno, desvincular al user del server.. pero en la practica..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ahi esta uno de los problemas, la unica conexion 100% confiable es la del server. Se podria buscar los user de mejor ping y usarlos de "reply".
El user reply se comunica con los que estan en su area visible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bueno, son un par de cosas que encontre mirando el codigo/se me ocurrieron mientras programaba.
1_En el sub UseInvItem del server, cuando manda el paquete para actualizar el inventario del cliente, note que actualizaba todo el inventario independientemente del slot que se haya usado. Esto explica el lag que causa tomar pociones, tirar flechas, talar o cualquier actividad similar. Para comprobarlo le agregue un server un contador de kbs enviados y recibidos x segundo, le pedi a 5 amigos que se logearan con unos pjs que tenian 10k de pociones cada 1 y que tomaran lo mas rapido posible todos a la vez. EL resultado fue entre 15 Y 20 kb de upstream del server consumidos, con solo 5 users...
En cambio, cuando puse especificamente en cada CASE del select que slot deberia ser actualizado(ejemplo, pociones, solo el slot de pociones, arco, ninguno ya que no cambia nada) no logro superar los 2.5kb.
2_Reemplace los mensajes de texto fijos que el servidor envia al cliente con "||blah blah" & fonttype... por codigos numericos, que se envian con un prefijo (por ejemplo use "!") y que el cliente, mediante un archivo init nuevo, cargado en un array, traduce al mensaje que es. Esto ayuda por el simple echo de que mandar "!" y un numero de maximo 3 digitos pesa menos que 2 oraciones enteras.
Bueno habia un par de cosas mas pero la verdad es que hace 2 semanas que me estoy acostando a eso de las 10 de la maana y la verdad en este momento no me acuerdo, cualquier cosa maana lo posteo
PD:Hice que el cliente pesara 130kb sacandole las imagenes que estan puestas fuera de run time (estan repetidas, las carga =) y haciendole UPX.
Saludos y posteen que me interesa su opinion.
Gracias, fer.
muy bueno
es buena la idea de los slots, existen otras cosas tambien para reduccion de lag que aver si me acuerdo de alguna.
Sobre los mensajes nose si viste las screens de ao-mistico, nosotros hicimos eso con gran parte de los mensajes, como estas perdiendo energia que se ve con unas hermosas luces al lado de hambre y sed junto con en veneno entre otros, tambien con otros como "estas demaciado lejos para comerciar" o "estas muerto, no puedes comunicarte con el mundo de los vivos" que fueron pasados al cliente.
de la interface te dejo este link como para que veas como queda, que ademas de sacar bruto cartel tambien queda mejor a la estetica.
despues lo pongo por que no responde el foro de alkon.
otras ideas para reducir el lag, es pasar las charfile a base de datos, nosotros lo hicimos de manera precaria a access cuando tendriamos que hacerlo sql y con un contador medimos los tics y es la relacion de 1000 tics en archivo.chr a 100 tics en db te pego el log.
19/01/2004 13:09:38 Ticks en SaveUserDB - 100
19/01/2004 13:09:51 Ticks en SaveUserDB - 40
19/01/2004 13:10:06 Ticks en SaveUserDB - 40
19/01/2004 13:13:12 Ticks en en SaveUser - 1061
19/01/2004 13:13:25 Ticks en en SaveUser - 1262
19/01/2004 13:13:42 Ticks en en SaveUser - 1292
otra cosa tambien puede ser el envio de mensajes por objetos, haciendo que los detalles de los objetos puedan estar en el cliente, para ser mostrados, no para calcular golpe y eso, ya que lo hace el server, pero el problema con esto es que tendria que estar en db todos los objetos, por que sino tardaria mucho en abrir el cliente tanto como lo hacia la version 0.9.9c y posteriores.
y bueno, no se me esta ocurriendo que mas.
Lo de los mensajes lo tengo echo con todos, y funca muy bien. Es un archivo de texto, como este:
[INIT]
Mensajes=253
[MENSAJES]
MENSAJE1=No pods tener mas objetos.
MENSAJE2=No tienes mas espacio en el banco!!
MENSAJE3=No ves nada interesante.
MENSAJE4=Has prendido la fogata.
MENSAJE5=No has podido hacer fuego.
MENSAJE6=%%%%POR FAVOR ESPERE, INICIANDO WORLDSAVE%%%%
MENSAJE7=%%%%WORLDSAVE DONE%%%%
Luego pasado a binario con un boton nuevo en el encoder. Es facil de hacer, quizas te tome un rato pasar los mensajes al txt pero despues es una webada, pero realmente ayuda.
y lo otro la verdad no se casi nada de DBs, pero a mi entender eso reduciria el tiempo de carga de las fichas, que seria mas bien un tema de maquina mas bien y no de conexion (corrijanme si me equivoco, no estoy seguro realmente). De todas maneras todo viene bien.
PD: te olvidaste el link =P
Hola grupo!
Me parece que con respecto al protocolo de AO1 es muy deficiente y algunas de las cosas que proponen mejoraria muchisimo el ancho de banda.
Tiempo atras yo habia rediseñado casi todo el protocolo server-cliente (lamentablemente lo perdi con una formateada).
Los cambios que le hice eran los siguiente:
Primero ningun mensaje en forma de texto era ENVIADO por el servido, sino que el cliente tenia una lista (mensajes.txt) con TODOS los mensajes, que de los cuales escojia el que necesitaba y el server lo unico que tenia que enviar era dos bytes, uno undicaba que el cliente tenia que mostrar un mensaje y el otro el indice del mensaje. En al caso de mensajes que contenian valores, por ejemplo "La criatura te a pegado por 10." donde esta el numero se lo reemplaza por un "%d" al mejor estilo printf. El server tendria que sumar unos bytes adicional, Comando-IndiceMSJ-Valores.
Ventajas: Ahorro significativo de ancho de banda, y cliente de AO traducible a otros idiomas (Como paso con AO2 isometrico).
Segundo el protocolo ya no enviaba strings sino que enviaba un byte (OLOGIN = 0, AT = 1, etc) que indicaba el cada comando. En el caso del comando "M" lo desplege en cuatro MN = 2, MS = 3, ME = 4, MO = 5. Todos los comandos se tranformarian en un gran ENUM que ayudaria mucho al server. Ya que la gran cantidad de IF y SELECT CASE con Left y Right quedan deprolijos y consumen micro de forma inecesaria. Dura tarea pero creo que aliviana mucho el lag.
Nunca lo pude probar con muchos users y creo que voy a volver a mis andansas.
quisiera saber si alguien ya puso manos en la masa?
Una preguntita sobre el CVS, puede ser que tenga pass el anonimo, si tiene pasenlo.
Leandro:
Ante todo gracias por los comentarios.
En cuanto a tu pregunta, si, esto es algo que se viene planeando (deseando, pidiendo, reclamando, implorando, etc) desde ya hace varios años. Además, hasta hace mese y medio (casi dos) el codigo que habia en el CVS tenia parte de tales cambios ya realizados, pero por motivos "administrativos" se hizo un rollback de todo.
Ahora mismo están planeados para las siguientes versiones, a realizarse e implementarse en forma gradual.
El CVS anonimo no tiene pass. El truco está en que solo podes entrar usando "pserver". SSH es solo para developers; si intentas entrar por SSH como anonimo no vas a poder (te pide la pass que vos pedís). Para mas informacion, metete en la seccion "CVS" del proyecto en SF:
https://sourceforge.net/cvs/?group_id=67718
Saludos,
Alejandro "Alejo"
esto se anda haciendo desde hace mucho..
http://www.alkon.com.ar/foro/ideas-y-desarrollo.109/269736-reduccion-peso-de-mensajes-del-protocolo.html
mira eso por ejemplo..
tambien subi la lista de translaciones de mensajes viejos a nuevos.. para facilitar el pasaje..
=)
Ante todo bienvenido!!
Como bien dijeron acá mis compañeros, esto es algo que se plantió muchas veces y hasta se implementó, pero como mencionó Alejo por problemas "administrativos" se debió hacer rollback. De todas formas, Imperium AO sí está usando el protocolo binario mencionado que yo había programado hace cerca de un año, y ha demostrado dar excelentes resultados (cayó el consumo de ancho de banda a la mitad).
El protocolo binario entra en la 11.6 reduciendo considerablemente el peso de muchos mensajes (en esta ocasión el diseño presenta algunas diferencias respecto a como lo hice el año pasado, básicamente para hacerlo más flexible y limpio, recordemos tuve bastante tiempo más para pensarlo y pulir el diseño), y en las versiones subsiguietnes 11.7 y 11.8 entran modificaciones del mismo (nuevos paquetes para subdividir a otros, unificación de paquetes que no se usan separados, etc.).
El no envio de mensajes de consola (salvo chats o cosas similares) es también algo que se va a realziar en estas versiones.
De más está decir que si te interesa colaborar con esto este es el lugar indicado para hacerlo pues en cuanto se comiencen los trabajos en la 11.6 todo esto estará siemrpe actualizado en el CVS.
Al parecer ya esta todo listo como para provocar un quiebre en el protocolo. Es posible poder ver un bosquejo de como va a ser implementado o que tienen en mente para que el grupo lo pueda analisar.
Otro pequeño truquito que me han comentado que se suele usar y que es denominado "reply" (creo). Consiste en que los mismos PJ se comuniquen enviando info de su propio estado (por ejemplo, pos X, Y, cosas equipadas, es fantasma, etc) para aminorar la carga en el server. Esto habria que analizarlo con detalle, ya que podria traer mas problemas de los que ya hay. Pero si funciona se podria generar una pequeña red P2P de datos "inocentes", que liberaria al server de esa carga para atender asuntos mas importantes.
Me voy a mantener al tanto de los avances.
Ya pude acceder al CVS :)
mm ese sistema lo tenia aplicado a mi mmorpg personal pero.. nunca lo testie con muchos users.. jejej =P
y a decir verdad, una gran parte de los usuarios de AO se conectan con dial up todavia.. o con maquinas no apropiadas para hacer de host.. asi que no se si sera buena idea ponerlo.. anque en teoria es bueno, desvincular al user del server.. pero en la practica..
Ahi esta uno de los problemas, la unica conexion 100% confiable es la del server. Se podria buscar los user de mejor ping y usarlos de "reply".
El user reply se comunica con los que estan en su area visible.