Martínez Navarro, Germán Fco.

Martínez Navarro, Germán Fco.

Índice • Introducción • Paquetes • Cuerpo del mensaje • Circuitos • Sistema de mensajes • Arquitectura del cliente • Arquitectura del servidor

Introducción (1/2) • Second Life (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.

Introducción (2/2) • SL usa como protocolo de transporte UDP (RFC 768) para intercambiarse información entre los visores y el simulador. • UDP no solicita reenvío de paquetes perdidos, lo que hace que sea ideal para servicios como video streaming. En nuestro caso esto supone una ventaja a la hora de enviar información sobre los escenarios.

Paquetes (1/4) • Cabecera: 4 5 6 N Byte 0 1

Paquetes (2/4) • Cabecera • Byte 0: • ZER: Los 0s en el cuerpo del paquete van codificados. • REL: El paquete fue enviado de forma segura. • RES: Este paquete es un reenvío de la fuente. • ACK: Este paquete contiene ACKs adjuntos (en la cola). • 4 bits menos significantes: Reservados. + -

Paquetes (3/4) • Byte 1-4: • Número de secuencia del mensaje (con ordenación big-endian). • Byte 5: • Cantidad de bits adicionales extras en la cabecera.

Paquetes (4/4) • Cuerpo: • (Byte 6+extra) hasta (6+extra+long. datos) • Cola: • La cola del paquete contendrá una serie de ACKs • (6+extra+longitud de los datos) hasta (final-1) • El último byte es una cuenta de cuantos ACKs contiene

Cuerpo del mensaje (1/3) • Se usan para enviar 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. • Existe una gran cantidad de mensajes. Una lista de ellos puede verser en: http://wiki.secondlife.com/wiki/Category:Messages

Cuerpo del mensaje (2/3) • Formato: Preámbulo Bloque Variable Tipo de dato

Cuerpo del mensaje (3/3) • Ejemplo:mplo:

Circuitos (1/2) • Un circuito es una conexión UDP entre dos nodos: • Visor-Simulador • Simulador-Simulador • Simulador-Servidor • Tipos: • Trusted • Untrusted

Circuitos (2/2) • Untrusted: • Todo circuito empieza siendo untrusted. • Las conexiones Visor-Simulador son de este tipo. • Cualquier mensaje seguro sobre un circuito de este tipo será descartado por el receptor. • Trusted: • Las conexiones Simulador-Simulador y Simulador-Servidor son de este tipo. • Estos circuitos se establecen en respuesta a los mensajes DenyTrustedCircuit haciendo uso de los mensajes CreateTrustedCircuit y un protocolo de confianza.

Sistema de mensajes (1/2) • Número de secuencia • El número de secuencia es creado en la conexión al circuito. • A partir de entonces los paquetes irán incrementando su número de secuencia. • 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. • 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.

Sistema de mensajes (2/2) • Confirmación de paquete • La fiabilidad no va implícita en el mensaje, si no que es especificada por el emisor en el momento de enviarlo. • 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. • 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. • Cuando A recibe ese paquete, remueve el número de ese paquete de su nodo de información. • 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. • Si después de 3 intentos, sigue sin recibir confirmación, el paquete es descartado.

Arquitectura del cliente (1/2) • El cliente de SL (también conocido como visor) permite visualizar el entorno virtual y los objetos que lo conforman. • El visor es un único proceso con varios hilos Main Error Worked VFS LFS Image Worked

Arquitectura del servidor (1/1) • La parte del servidor ya no es open source. • 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 12036 del servidor. • Simulador: • Es el proceso principal del servidor. • Cada simulador es capaz de procesar una región de 256x256 metros. • Se encarga de calcular qué objetos son visibles en todo momento. • Envía las imágenes de forma priorizada. • Mensajes de chat también son procesados por él. • Los simuladores se comunican entre ellos mediante circuitos UDP.

Bibliografía • http://wiki.secondlife.com/wiki/Protocol

Martínez Navarro, Germán Fco.