Martínez Navarro, Germán Fco.

Transcripción

1 Martínez Navarro, Germán Fco. Ampliación de Redes

2 ÍNDICE 1 Introducción Paquetes Cuerpo del mensaje Circuitos Sistema de mensajes Arquitectura del cliente Arquitectura del servidor

3 1 INTRODUCCIÓN Second Life (abreviado SL) es un metaverso lanzado el 23 de junio de 2003, desarrollado por Linden Lab, y es accesible gratuitamente en Internet. Sus usuarios, conocidos como "residentes", pueden acceder a SL mediante el uso de uno de los múltiples programas de interfaz llamados viewers (visores), lo cual les permite interactuar entre ellos mediante un avatar. Los residentes pueden así explorar el mundo virtual, interactuar con otros residentes, establecer relaciones sociales, participar en diversas actividades tanto individuales como en grupo y crear y comerciar propiedad virtual y servicios entre ellos. El usuario accede a los metaversos a través de su representación del yo virtual: los avatares. Los avatares son caracteres tridimensionales personalizables lo que le da a los usuarios la capacidad de convertirse el personaje que deseen y "gozar" de una segunda vida. Su segundo atractivo más importante es la posibilidad de crear objetos e intercambiar diversidad de productos virtuales a través de un mercado abierto que tiene como moneda local el Linden Dólar (L$). En el mismo programa se incluye una herramienta de creación en 3D basada en simples figuras geométricas (conocidos como prims o primitivas) y que permite a los residentes la construcción de objetos virtuales. Con lo que un usuario puede, o bien comprarse un coche, o crearlo él y venderlo o usarlo. Estos elementos pueden usarse en combinación con el lenguaje de programación LSL o Linden Scripting Language a fin de añadir funcionalidad a los objetos. SL emplea como protocolo de transporte UDP para intercambiar información entre los visores y el simulador. Al igual que para servicios como video streaming UDP es perfecto, ya que para cada paquete enviado no hay que esperar confirmación (si no se vería los videos a golpes), para el mundo de SL pasa algo parecido, ya que, entre otras cosas, en todo momento se ha de enviar el estado y forma del mundo, y este ha de ser un proceso rápido de recepción de los objetos, coordenadas, avatares, y pintarlos en el ordenador del cliente. 3

4 2 PAQUETES Cualquier paquete intercambiado dentro del mundo de SL tiene el siguiente formato: Cabecera: o Byte 0: LL_ZERO_CODE_FLAG: Los 0s en el cuerpo del paquete van codificados. Esta es la forma en la que se comprimen los paquetes a la hora de ser enviados. LL_RELIABLE_FLAG: SL no tiene un mecanismo implícito de envío seguro, se ha de indicar en el propio paquete si se desea enviar de forma segura o no. Esto influirá sobre el paquete a la hora de enviarlo por un circuito seguro o no (ya se verá más adelante) LL_RESENT_FLAG: Este paquete es un reenvío de la fuente en caso de haberse solicitado el reenvío del mismo. LL_ACK_FLAG: Este paquete contiene ACKs adjuntos (en la cola). Los 4 bits menos significativos no se usan. o Byte 1-4: Número de secuencia del mensaje o Byte 5: Cantidad de bits adicionales en la cabecera. o Byte 6+N: Información adicional. Cuerpo: Del byte6+extra al 6+extra+long. Datos. En el van los datos (en el siguiente apartado se verá el formato de éstos). Cola: En la cola del paquete es donde se adjuntan todos los ACK, siendo el último de ellos el que indica la cantidad de ACKs que viajan con el paquete. 4

5 3 CUERPO DEL MENSAJE Dentro de los mensajes se envía la información serializada entre los clientes y el servidor, a través de conexiones conocidas como circuitos. En todos los mensajes se debe realizar un comprobación del CRC entre ambos hosts, si no la comunicación no tendrá éxito. El formato del cuerpo es siempre el mismo: Preámbulo: Contiene información acerca del mensaje: o Name: Nombre del tipo de mensaje o Frecuency: High / Medium / Low / Fixed [U32]. Determina si el ID del paquete es de 8, 16 o 32 bits. Un valor Fixed define el propio ID del paquete y son considerados señales. o Trust level: Trusted / NotTrusted. Indica el nivel de confianza necesario por el circuito entre el emisor y el receptor para que el mensaje sea enviado correctamente. o Encoding: Unencoded / Zerocoded. Codificación Zerocoded realiza una compresión de secuencias de ceros en el mensaje de manera que se reduzca la carga en la red. Si después de la compresión no hay mucha diferencia respecto al paquete sin comprimir, se envía sin comprimir. Bloque: Los bloques delimitan grupos de datos dentro del mensaje: o Name: Nombre del bloque. o Quantity: Single / Multiple [U8] / Variable. Determina cuantos bloques de ese tipo hay contenidos dentro del mensaje. o Single: 1. o Multiple: Indica una cantidad fija. En este caso a continuación viene un número de 8 bits indicando la cantidad de veces que se repite este bloque. o Variable: Permite especificar la cantidad de bloques. Variables: Contienen los datos enviados en el mensaje: o Name: Nombre de la variable. o Type: Valores simples: Null / Fixed [U32] / Variable [U32] / U8 / U16 / U32 / U64 / S8 / S16 / S32 / S64 / F32 / F64 Contenedores: LLVector3 / LLVector3d / LLVector4 / LLQuaternion / LLUUID / BOOL / IPADDR / IPPORT / U16Vec3 / U16Quat / S16Array Type: Tipos de datos: o Null - no data, 0 bytes wide 5

6 o Fixed - byte array, interpreted depending on packet type, width determined in message definition o Variable 1 - first byte determines number of bytes that follow (U8) o Variable 2 - first two bytes determine number of bytes that follow (U16, big-endian in UDP Packet Layouts). o U8 - unsigned byte, 1 byte wide o U16 - unsigned short, 2 bytes wide (little-endian in UDP packet layouts) o U32 - unsigned int, 4 bytes wide (little-endian in UDP packet layouts) o U64 - unsigned long, 8 bytes wide (little-endian in UDP packet layouts) o S8 - signed byte, 1 byte wide o S16 - signed short, 2 bytes wide (little-endian in UDP packet layouts) o S32 - signed int, 4 bytes wide (little-endian in UDP packet layouts) o S64 - signed long, 8 bytes wide (little-endian in UDP packet layouts) o F32 - float, 4 bytes wide o F64 - double, 8 bytes wide o LLVector3 - triplet of floats, 12 bytes wide o LLVector3d - triplet of doubles, 24 bytes wide o LLVector4 - quad of floats, 16 bytes wide o LLQuaternion - because it's always a unit quaternion, transmitted in messages as a triplet of floats, 12 bytes wide (represented in memory as a quad of floats, 16 bytes wide) o LLUUID Universal ID, 16 bytes wide o BOOL - 0 or 1, 1 byte wide o IPADDR - IP Address, one place per byte, 4 bytes wide o IPPORT - IP Port, two bytes wide o U16Vec3 - not used o U16Quat - not used o S16Array - not used 6

7 4 CIRCUITOS Un circuito es una conexión UDP entre dos nodos: o Visor-Simulador o Simulador-Simulador o Simulador-Servidor Existen dos tipos de circuitos, trusted y untrusted. Los circuitos están construidos sin gestión de sesiones personalizadas, por lo que los procesos que controlan cada uno de los 2 nodos de la conexión pueden desaparecer y provocar que éste se reinicie. Debido a esto, no se puede predecir con exactitud si un nodo confía en otro, ya que puede haberse reiniciado después de haberse establecido la conexión con anterioridad. Dado que los circuitos son maneados por el sistema de mensajes, el circuito se establece llamando a una función enablecircuit. El establecimiento de la confianza del circuito también se establece en la creación del mismo. Un circuito de confianza no se crea a menos que se envíe un mensaje CreateTrustedCircuit. Untrusted: Todo circuito empieza siendo untrusted, y es el tipo de circuito que se establece entre visor-simulador. Cualquier mensaje trusted enviado sobre un circuito untrusted será descartado por el nodo receptor. Trusted: Sólo existen entre conexiones del simulador con el mismo y/o con el servidor. Estos circuitos se establecen en respuesta a los mensajes DenyTrustedCircuit haciendo uso de los mensajes CreateTrustedCircuit y un protocolo de confianza. 7

8 5 SISTEMA DE MENSAJES Dado que todos los mensaje van sobre UDP, de alguna manera se ha de comprobar mensajes redundantes, si estos se recibieron o no, Número de secuencia: El número de secuencia del paquete es un número de 24 bits creado en cuanto el paquete se conecta al circuito. Este número es almacenado en la cabecera del paquete, e irá incrementándose a medida que se vayan intercambiando paquetes. Eliminación de duplicados: Dado que no hay garantía en la entrega de los paquetes, el propio circuito es quien debe encargarse de eliminar repetidos. Para ello el circuito tiene una lista de todos los paquetes que recibió recientemente, a través de un valor de tiempo determinado. Si un paquete que ya está en esta lista se recibe una vez más, el circuito responde con otro ACK adjuntado al paquete siguiente. Confirmación de la recepción: Como ya se comentó, la seguridad no va implícita en el mensaje, debe ser especificado en el paquete en el momento de enviarlo. 1. Cuando A envía el mensaje, activa el flag de REL y se guarda en un nodo de información el número de ese paquete. 2. Cuando B lo recibe, envía este número al final del paquete que envíe a A, activando también el flag de ACK. 3. Cuando A recibe ese paquete, remueve el número de ese paquete de su nodo de información. 4. Si en un tiempo máximo (determinado por el retardo de realizar un ping por el circuito) A no recibe confirmación, el paquete es reenviado. 5. Si después de 3 intentos, sigue sin recibir confirmación, el paquete es descartado. 8

9 6 ARQUITECTURA DEL CLIENTE El cliente de SL, también conocido como visor, permite visualizar el entorno virtual y los objetos que lo conforman. Este visor es un único proceso con varios hilos: o Hilo Main: Donde se produce toda la entrada/salida del programa. Además actúa de renderizar el escenario. o Hilo VFS (Virtual File System): Encargado de la lectura/escritura del sistema de archivos virtual local. o Hilo LFS (Local File System): Encargado de algunas de las lecturas/escrituras realizadas en el sistema de archivos nativo local. o Hilo de imagen: Hilo responsable de solicitar y decodificar los datos relativos a imágenes. o Hilo de error: Hilo encargado de la captura de excepciones, que posteriormente invoca al gestor de errores. Actualmente no se usa. o Hilos de trabajo: Encargados de realizar las tareas que van a la CPU. Para reducir la carga durante el renderizado, estos hilos se suelen parar. 7 ARQUITECTURA DEL SERVIDOR Esta parte ya no es de código abierto a diferencia del cliente. A lo largo del documento se ha mencionado muchas veces el término simulador, pero qué es el simulador? El simulador no es más que el proceso principal del servidor. Cada simulador es capaz de procesar una región de 256x256, por lo que para los mundos realmente amplios son necesarios varios simuladores para gestionarla, todos ellos dentro del mismo servidor, comunicándose entre ellos mediante circuitos UDP. Por ejemplo, el proceso de login. El encargado de comprobar el logueo es un script CGI. Hace uso del protocolo XML-RPC sobre HTTP, y se envía al puerto del servidor. NOTA: XML-RPC es un protocolo de llamada a procedimiento remoto que usa XML para codificar los datos y HTTP como protocolo de transmisión de mensajes. 9

10 BIBLIOGRAFÍA 10