Días pasados, a finales de junio, Linden Lab anunció en su blog oficial que sus desarrolladores se encuentran abocados enteramente a estudiar, analizar y solucionar los problemas de lag en Second Life.
Según lo informado por la empresa, están realizando una gran inversión en actualización de hardware para sus servidores con el fin de potenciar las prestaciones de los mismos. Además, los 3 datacenters donde tenían sus servidores han sido reducidos a 2, con lo cual, siempre según la empresa, esperan reducir los tiempos de latencia en la interconexión entre sus servidores. (siendo mal pensados tambien puede deducirse que dicha reducción es para abaratar costos y compensar la pérdida de clientes propietarios de regiones que dejan servidores inactivos).
Por otro lado, a nivel desarrollo de software, se presenta el proyecto Shining (brillante), el cual, se divide en tres sub proyectos:
1) Proyecto Sunshine: O también «Server-Side backed Textures». Esto es, históricamente, el armado de las texturas del avatar se hace a nivel cliente (visor). Este, al iniciar sesión, cambiar ropa o skin, revisa en el inventario del usuario lo que lleva vestido, se encarga de vestirlo y generar lo que se denomina «backed texture», es decir, la textura compuesta por todo lo que llevamos vestido. Luego, obtenida ésta, se envía al servidor del sim donde está el usuario para que éste envíe esa información al resto de los usuarios en el mismo sim. Como este proceso contiene medidas de seguridad para evitar la transferencia de información errónea por problemas de red, se vuelve lento y molesto, lo que provoca el tan famoso y temido efecto «nube» o de ropas u objetos que no se cargan.
El proyecto sunshine tiene por objetivo minimizar este problema y lo hará derivando la carga del renderizado del «backed texture» a un servidor central dedicado exclusivamente a esa tarea, al cual se lo denomina «Servidor de Texturas», aliviando asi, la carga de renderizado del visor (con esto se eliminaría el lag gráfico del lado del visor). Este proceso implicaría que, una vez puesto en marcha el sistema, el visor le indicaría al servidor del sim que necesita renderizar un avatar, entonces, este servidor le hace la petición al «servidor de texturas», el cual, procederá a efectuar el renderizado y devolverlo al sim para que lo entregue al usuario peticionante. Además, el servidor de texturas, tendrá su propio caché de texturas renderizadas, por consiguiente, en el caso de recibir una petición de renderizado de un avatar que ya ha hecho (y este no ha cambiado), en vez de renderizarlo nuevamente, enviará el resultado alojado en su caché interno.
2) Cacheado de Objetos y Lista de Intereses: La idea de mantener un caché de objetos y texturas en el disco rígido del usuario (client-side) es acelerar los tiempos de carga evitando que nuestro visor intente descargar del servidor algo que ya hemos descargado en la sesión actual en alguna previa y aún no sido modificado. Actualmente el visor sólo almacena en caché aquello que esta en su área de visión y en el punto en que el usuario se desconecta de la región (ya sea por cerrar sesión o por teleportarse a otra región). Según Linden Lab este método es ineficiente y exige un alto consumo de recursos.
Con el nuevo sistema, cuando el visor se conecte a una región, el Sim le informará al visor la lista de objetos agrupados por UUID que tiene a su disposición, el visor la comparará con su caché y le responderá informándole al sim la fecha de creación de los objetos que tiene en caché. El sim comparará ambas fechas y si las propias son mas nuevas, le enviará al visor los objetos actualizados. Cabe destacar que si un objeto no está en el caché del visor, su fecha será cero (0), con lo cual, ese objeto será enviado al visor por el sim. Entonces, mientras el visor comienza a dibujar los objetos de su caché, paralelamente, recibirá del sim los nuevos objetos para dibujar a posteriori.
3) Librería HTTP: Aquí, la información provista por Linden Lab es escasa y sólo se limita a aclarar que el mejor funcionamiento del proyecto shining depende en gran medida de una buena comunicación a nivel servidor y cliente vía HTTP, por lo cual, los desarrolladores se encuentran abocados en el desarrollo de una nueva librería mejorada para poder sustentar todo el proyecto.
A primera vista, el proyecto es ambicioso y, creo, en la teoría se ve bastante bien, veremos que ocurre en la práctica ya que todo depende del desarrollo de cada uno de los 3 items enunciados. Y aquí es donde puedo llegar a tener algunos temores. Linden Lab, estos últimos años, ya ha dado pruebas suficientes de falta de confiabilidad a la hora de tocar el código de sus productos, provocando dolores de cabeza cuando se implementan cambios ambiciosos con pocos resultados satisfactorios, cuando no nulos o contraproducentes.
Respecto a su implementación cuando llegue el momento, es otro tema a tener en cuenta. En base a los informado por la empresa, es de suponer que los visores, tanto el oficial como los de terceros, deberán adaptar su código y rutinas a las nuevas metodologías, lo cual implica que Linden Lab deberá publicar las especificaciones de cada método utilizado y pautar un programa de migración adecuado y ordenado. Además, otra incógnita a resolver es si LL mantendrá ambos sistemas en forma paralela durante la transición o hará un cambio abrupto de un sistema a otro llegado el momento.
Por lo pronto, todo muestra que estamos recién en la etapa del papel y aún falta tiempo para comenzar a ver algunas pruebas de este proyecto para poder evaluar su impacto en la eterna lucha contra el lag en Second Life.
SaludOS/2