Capitulo 8

1 VRML 2.0 con Java CAPÍTULO 8

Multiusuario de Tecnologias

2 VRML 2.0 con Java CAPÍTULO 8

Contenido CAPÍTULO 8

• Conceptos básicos • El Open de la Comunidad Propuesta • La API de CyberSockets

Conceptos básicos Como se recordará de nuestra discusión de la propuesta de mundos de vida en el capítulo 7, hay una serie de componentes en un sistema multiusuario. Estos componentes se ilustra en la Figura 8.1.

3 VRML 2.0 con Java CAPÍTULO 8

Figura 8.1 Los componentes de un sistema multiusuario El "multi-tecnología" ofrece una interfaz entre el navegador VRML y añadido de las comunicaciones de red, que suele ser el de Internet. Debajo de la MUtech se encuentra la pila de protocolos de redes, en el caso de Internet, se trata de UDP y TCP ejecutándose encima de IP (Protocolo Internet). Por encima de la MUtech se encuentra la propia solicitud, y el multiusuario que existe en la API de la interfaz. Vivir el universo conceptual de las normas "por encima" de esta capa, ya que oculta la vida Mundos API dentro de su MUtechZone, MUtechSharedObject, y MUtechPilot nodos. Así que tenemos una API de más arriba, y la Internet por debajo de lo que sucede en entre? Eso es una cuestión interesante, y no hay una respuesta única. Cada MUtech comienza con una configuración ligeramente distinta de las hipótesis, y por lo tanto, cada uno tiene una diferente arquitectura interna. Por eso vamos a estar buscando a dos MUtechs en este capítulo en lugar de uno solo, es importante entender cómo pueden ser diferentes.

Por qué necesitas un API A primera vista, puede parecer que no necesitamos un estándar API. Después de todo, la intención de los mundos de vida es ocultar los detalles de la MUtech, ¿por qué los exponen al hacer visible la API? Hay una serie de razones. Vida Mundos VRML es muy específica, es decir, se asume que cada participante en la simulación se está ejecutando el equivalente de un navegador de VRML. Sin embargo, este supuesto no podrá ocupar para una variedad de aplicaciones. Por ejemplo, algunas aplicaciones no necesariamente implican el uso de gráficos 3-D, o, en este caso, no podrá utilizar en todos los gráficos, un sistema basado en la API separa limpiamente hacer temas de redes de temas, y por lo tanto es más flexible. Incluso en aquellas aplicaciones que hacen uso de VRML, existe a menudo una necesidad de acceder a la API. Por ejemplo, considere la posibilidad de un mercado de valores en los que la solicitud de ubicación, tamaño, y color de los

4 VRML 2.0 con Java CAPÍTULO 8

objetos en un mundo VRML se usan para indicar el valor de las diversas poblaciones. Los datos de los saldos procedentes de algunos es el legado del sistema (normalmente, una antigua central) para los que no se dispone de navegador de VRML. Con el fin de construir un sistema de este tipo totalmente en torno a los mundos de vida, la persona que el sistema en conjunto tendrán que aplicar bien una gran parte de la funcionalidad de un navegador de VRML sobre ese legado sistema (que sería de una gran empresa) o poner un sistema adicional en lugar de actuar como un puente entre los dos (lo que sería un kludge). Si el legado del sistema tiene acceso a una API de multiusuario, sin embargo, entonces el problema está resuelto. Por supuesto, uno también podría preguntarse por qué no sólo estandarizar el formato de los datos que fluyen a través de la red. Cualquier sistema con una pila TCP / IP podrían entonces a la interfaz multi-tecnología, lo que haría posible la aplicación de la tecnología multi-sobre una amplia variedad de plataformas, garantizando que todos los sistemas multiusuario puede interactuar (que no pueden, en virtud de Vida Mundos). Sin duda, esto va a pasar el tiempo, ya que las ventajas de tener un protocolo estándar "sobre el alambre" son importantes. Desafortunadamente, no hay aún propuestas sólidas para este nivel de normalización. Además, todos están de acuerdo en que es realmente demasiado pronto para empezar a normalizar en ese nivel, nadie sabe realmente lo que son los mejores planteamientos, y todavía tenemos que experimentar mucho más. Incluso una cuestión tan básica como cliente-servidor, frente multicasting aún no se ha resuelto. Sino por la normalización a nivel de la API, en lugar de los más de los hilos de protocolo, podemos construir mundos multiusuario de inmediato sin tener que finalizar cualquier aplicación bajo nivel de decisión. La capa de API no permite la plena interoperabilidad, pero sí permite la interoperabilidad entre las plataformas que utilizan un determinado MUtech. Por ejemplo, que cualquier plataforma de funcionamiento del Abierto Comunidad pueda interoperar con cualquier otra plataforma ejecutando Open Comunidad. Del mismo modo, cualquier plataforma que soporte CyberSockets será capaz de interoperar con cualquier otra plataforma CyberSockets. Sin embargo, no se puede "mezclar y combinar", un mundo virtual, debe utilizar un determinado MUtech. Afortunadamente, la Vida Mundos propuesta establece un camino para los creadores de contenido a ignorar las cuestiones de interoperabilidad y para crear objetos que se pueden utilizar con cualquier MUtech. Esto permite a los usuarios crear avatares reutilizables para sí mismos, así como los objetos que funcionan en cualquier sistema.

5 VRML 2.0 con Java CAPÍTULO 8

¿Tiene lo que el MUtech El MUtech realiza una amplia gama de funciones, pero la idea básica es muy simple. Un MUtech permite que varios sistemas de computadoras para conectarse entre sí y comparten un mismo mundo virtual. El MUtech es responsable de mantener un "estado" para el mundo virtual, de modo que la copia del mundo que existe en un equipo del usuario es realmente idéntica a la copia que existe en cualquier otro equipo del usuario. También prevé la comunicación entre las entidades en el entorno virtual.

Funcionalidad básica El MUtech mantiene una copia local de los datos que describen el mundo. Hace que los datos disponibles para la aplicación local y permite la aplicación local de hacer cambios a los datos, que luego se propagó a otras máquinas de la red. El MUtech es responsable de garantizar que esta "base de datos distribuida" es coherente. Por ejemplo, si alguien abre una puerta o se enciende una luz, que la información debe ser transmitida a todos los otros hosts de modo que los usuarios sobre los anfitriones ver el estado de la puerta o la luz. El término entidad se utiliza a menudo para referirse a algún objeto en el entorno virtual cuyo estado puede cambiar con el tiempo. Un avatar es un tipo especial de entidad que pasa a estar bajo el control de un ser humano, en efecto, un avatar es el "cuerpo virtual" al usuario cuando se habita en la simulación. Cuando llega una nueva entidad en el entorno virtual, la MUtech debe añadir que la entidad a la copia local del mundo. Del mismo modo, las entidades que salen de la simulación debe ser eliminado. Como una entidad cambia de estado, cada host de la copia local de esa entidad del Estado debe ser actualizado. En cierto sentido, la MUtech aplica una especie de sistema de base de datos en la que las entidades se pueden añadir, eliminar y modificar. El MUtech es responsable de asegurar que cada entidad tiene un "locus de control" en un momento determinado. En el caso de los avatares, el locus de control suele ser algún tipo de panel de control o sistema de captura de movimiento que permite a un usuario humano para operar su auto virtual. En el caso de entidades que no están bajo el control humano directo, la MUtech debe hacer posible que el comportamiento del objeto a ser administrado por un proceso en la red. El MUtech también debe mediar en el intercambio de información entre entidades. Por ejemplo, el usuario lo desea, puede enviar mensajes de texto entre sí, los mensajes se transmiten por la MUtech. Del mismo modo, los sistemas que soportan audio en tiempo real permitiría la comunicación de voz entre usuarios; esas conversaciones también sería gestionada por la MUtech.

6 VRML 2.0 con Java CAPÍTULO 8

Por último, el MUtech necesidades para proporcionar un mecanismo por el cual las entidades pueden interactuar entre sí. Aunque los detalles de cómo un MUtech realiza estas tareas MUtech varían de una a otra, MUtechs todos tienen algunos elementos en común. Ya que está "negro cajas," podemos comenzar a examinar por mirar las cosas que está adherida. Como vimos en la Figura 8.1, la MUtech las interfaces de la aplicación (y el navegador de VRML), por un lado, y con el Internet en el otro lado.

Debajo de la Red Desde la MUtech ejecuta a través de Internet, que utiliza el protocolo estándar de Internet. El protocolo fundamentales en la Red es la propiedad intelectual, el Protocolo de Internet. Por encima de esto son otros dos protocolos: UDP y TCP. El MUtech utiliza UDP y TCP para comunicarse con otras copias de sí mismo o con un servidor remoto proceso de algún tipo. UDP, el Protocolo de datagramas de usuario, está diseñado para las comunicaciones entre la conexión de Internet. Cada paquete es independiente, y un solo mensaje de los protocolos de más alto nivel se suele almacenar en un solo paquete UDP. Paquetes UDP son "poco fiables" en el sentido de que pueden ser descartados simplemente cuando la red se convierte en sobrecarga, y por lo que su entrega no está garantizada. Aquellos paquetes que no llegan no están garantizados para llegar en el mismo orden en que fueron enviados. TCP, por el contrario, es una relación orientada al protocolo. Utiliza un enfoque de flujo de bytes, en el que un flujo continuo de datos está dividido en piezas para transmisión. Cada pieza de datos se le asigna un número de secuencia, y TCP tiene el reconocimiento y la retransmisión de mecanismos que garanticen que los datos se reconstruyó en la secuencia correcta, independientemente de las condiciones de la red. Es la ausencia de estos mecanismos que hace diferente a UDP TCP. La mayoría de las aplicaciones que se ejecutan a través de Internet el uso de TCP. Cada aplicación utiliza un protocolo particular que se ejecuta "en la parte superior de" TCP, y que se basa en TCP fiable para proporcionar una interfaz de flujo de bytes. Por ejemplo, la World Wide Web utiliza HTTP (Hypertext Transfer Protocol) por encima de TCP. El correo electrónico es enviado a través de SMTP, el Simple Mail Tranfer Protocolo, que a su vez se ejecuta en TCP. Del mismo modo, utilizando noticias NNTP viajes, la Red de Protocolo de transferencia de noticias. Sin embargo, TCP tiene algunos problemas serios cuando se trata de mundos en tiempo real multiusuario. El muy características que lo hacen tan útil para muchas otras aplicaciones realmente añadir una enorme cantidad de gastos generales. Cada paquete tiene que ser reconocido y secuenciado, lo que aumenta el ancho de banda y aumenta la utilización de procesamiento generales. Dado que todos los paquetes en un flujo TCP debe llegar en el orden

7 VRML 2.0 con Java CAPÍTULO 8

en que se envió, la retransmisión y la memoria es a menudo necesario, causando el aumento de la latencia y la información para llegar mucho después de haber sido enviado. No es raro que los retrasos de varios cientos de milisegundos que se produzcan en los períodos punta. Para el correo electrónico, que no es un problema, para la interacción en tiempo real, es desastroso. Por esta razón, casi todos los sistemas de multi-uso de UDP para la mayoría de su estado de actualización de información. Una forma de sortear el carácter poco fiable de utilizar UDP es un protocolo sin estado en el que cada paquete contiene una descripción completa del estado actual del objeto. (El protocolo es "apátrida", ya que no hace ninguna suposición sobre el estado anterior del objeto en el lado del cliente). Si un paquete se pierde, se hace casi ninguna diferencia, que habrá otro a lo largo de unos pocos milisegundos que contendrá toda la información pertinente. Así como HTTP, SMTP, y NNTP son protocolos que se ejecutan por encima de TCP, es necesario que haya un conjunto de protocolos que se ejecutan en la parte superior de la UDP (y posiblemente de TCP) para el intercambio de información sobre las entidades estatales en el mundo virtual . Como se describió anteriormente, esta "over-the-wire" protocolo no se ha normalizado, lo que significa que cada MUtech sólo puede comunicarse con otras copias de sí mismo que utilizan el mismo protocolo. Tenga en cuenta que algunos sistemas usan ambos UDP y TCP. UDP se utiliza para las actualizaciones de estado en tiempo real, mientras que TCP se usa para transferir otros tipos de datos (tales como descripciones detalladas de las entidades).

Sobre la Aplicación Tanto de los ejemplos vamos a ver en este capítulo se han diseñado como las bibliotecas de clases de Java, ya que Java es el lenguaje de programación más popular para aplicaciones en red en Internet. Como vimos en la Figura 8.1, la aplicación se comunica con el navegador de VRML, por un lado y el MUtech por el otro. La comunicación con el MUtech se maneja a través de una API, y cada una de las propuestas examinadas en este capítulo son las descripciones de este tipo de una API. Como veremos, son bastante diferentes en términos de su enfoque. También son no sólo la API en la ciudad, tiene su propia Sony, por ejemplo, al igual que otros vendedores. En la mayoría de los casos, los vendedores han optado por no exponer sus MUtech API. Comunidad abierta y CyberSockets se eligieron para este capítulo, ya que ambos han proporcionado una amplia documentación sobre su funcionamiento a fin de permitir a terceros el desarrollo de aplicaciones.

El Open de la Comunidad Propuesta Hasta el momento la única propuesta formal de un "abierto" multiusuario API

8 VRML 2.0 con Java CAPÍTULO 8

Abierta Comunidad, presentadas por una coalición de empresas, entre ellas Chaco Comunicaciones, Velocidad (ahora I-juegos), y los mundos, Inc. Abrir Comunidad se basa en la SPLINE (Scalable Plataforma de entornos interactivos) sistema, desarrollado originalmente por los laboratorios de investigación de Mitsubishi Electric (Merl). En él se describe un API que se implementa como una biblioteca de clases de Java, aunque C vinculantes también se espera que estén disponibles. Aunque la propuesta de la Comunidad Abierta se remonta sólo a octubre de 1996 (cuando se introdujo por primera vez como Universal Mundos), es sobre la base de los muchos años de investigación y desarrollo que llevó a la creación de SPLINE. SPLINE en desarrollo, los investigadores de Merl abordado muchos de los problemas básicos comunes para entornos multiusuario y encontró interesantes soluciones a muchos de ellos. SPLINE se ha utilizado con éxito en la creación de un rico, llamado entorno multiusuario Diamante Park (se muestra en la Figura 8.2).

Figura 8.2 Diamante Park Los debates entre los representantes de la Comunidad Abrir grupo y el grupo de los mundos de vida han indicado que las dos propuestas son complementarias, ya que hacer frente a diferentes partes del mismo problema general. Mundos de vida, mientras que los intentos de crear normas para compartir contenido de VRML, Open Comunidad multiusuario ofrece normas para los protocolos en el nivel de la API. Desde la perspectiva de los mundos de vida, Open Comunidad es simplemente una tecnología multiusuario.

Ocultar la Red El Open de la Comunidad de API no exponer a la red de desarrolladores de la aplicación. De hecho, el código de la aplicación funcionará exactamente de la misma forma si todo el mundo reside en una sola máquina o distribuidos en un número arbitrario de máquinas de una red. Desde el punto de vista del desarrollador de aplicaciones, es simplemente una cuestión de acceso a

9 VRML 2.0 con Java CAPÍTULO 8

objetos de datos en su máquina local. Todo el mecanismo de replicación de estado-es casi totalmente transparente.

Base de datos compartida Comunidad abierta trata el mundo como una especie de base de datos compartida, cada huésped parece tener acceso a todo el mundo, pero en realidad sólo tiene un subconjunto del mundo cargado en un momento dado. Abrir esta Comunidad es la carga dinámica por las partes del mundo que son pertinentes en un momento determinado y descarga de las partes que no son pertinentes.

N servidor central Abrir el dibujo o modelo comunitario acaba con la idea de un gran servidor central, a favor de un enfoque totalmente distribuido. Este diseño es muy importante, ya que la experiencia ha demostrado que los enfoques de servidor central no escala bien. Incluso en texto simple basado en entornos multiusuario, las demandas sobre la memoria, poder de procesamiento, ancho de banda y siempre han sido un problema grave, y 3-D entornos multiusuario con sonido en tiempo real de poner aún más presión sobre un servidor central. Comunidad abierta no es el único en abandonar el modelo de servidor central. DIS (Distributed simulación interactiva) es también Serverless sistema, como es el DIVE (Distribuido Entorno Virtual Interactivo) sistema de el Instituto Sueco de Ciencias de la Computación. Muchos otros investigadores han propuesto modelos similares. Nota: Más información acerca de DIS se puede encontrar en la http://www.sc.ist. Uct.edu / ~ ETS / y en http://www.dmso.mil/projects/hla. Más información acerca de BUCEO se puede encontrar en la http://sics.se/dce/dive/dive.html.

Particionado espacial Cuando el ancho de banda es limitado, es importante para enviar mensajes de actualización sólo para las entidades en que el usuario puede ver, e ignorar las que están demasiado lejos o bloqueados por otros objetos. Aprovechándose de las riquezas naturales y causadas por el hombre, los obstáculos en el medio

10 VRML 2.0 con Java CAPÍTULO 8

ambiente, es posible hacer algunas de filtrado inteligente de la información. Comunidad ha abierto un concepto de "regiones" que ofrecen esta capacidad.

Soporte para sonido Comunidad abierta a prestar apoyo a tiempo real, spatialized de audio, que se manejan de la misma manera que otros datos del mundo. En particular, esto permite el uso de la palabra y de otros tipos de sonido para enriquecer el entorno virtual.

Uso de las normas existentes El Open Comunidad MUtech utiliza protocolos de Internet existentes de buena parte de su bajo nivel de funcionalidad. En particular, utiliza HTTP para la transferencia de cosas tales como las descripciones de VRML, sonidos y comportamientos. Utiliza la RTP (Real-Time Protocol), protocolo de streaming en tiempo real de datos, y utiliza UDP para enviar pequeñas, rápidamente cambiante de datos (como el avatar posiciones). Con el formato actual de los datos que se transfieren también se adhiere a los estándares web, tales como VRML para gráficos 3-D y WAV (y otros populares formatos de sonido) para el audio.

Arquitectura del sistema Abrir el sistema comunitario se compone de un modelo de mundo, que es esencialmente un compromiso de base de datos orientada a objetos. La variables de instancia de objetos en el mundo corresponde al modelo de base de datos de lo que parece una "entidad estatal" la información, y actualización de las variables de instancia (utilizando métodos adecuados de los objetos) es el mecanismo para la actualización de un objeto del estado tanto a nivel local y en todo el mundo definido por la MUtech. Este modelo básico se muestra en la Figura 8.3.

11 VRML 2.0 con Java CAPÍTULO 8

Figura 8.3 El modelo de la Comunidad Abierta Cada objeto en la base de datos se supone que es controlado por un solo proceso en un momento determinado. Esto se corresponde con el concepto de "locus de control", que hemos hablado anteriormente en este capítulo. En particular, la persistencia de los objetos está ligada a la existencia de la propiedad de su proceso; una vez que el proceso se va, también lo hace el objeto. La aplicación está a cargo y con carácter periódico a su vez el control sobre el Open Comunidad MUtech llamando a la spWM.Update () método. Durante la presente convocatoria, Open Comunidad actualizar los objetos en la versión en caché local de la base de datos basado en los cambios que se han hecho en otras partes y le enviará los cambios locales en todo el resto de la red. Dado que el usuario sólo puede ver y escuchar una pequeña parte de los entornos virtuales en un momento determinado, Open Comunidad dinámicamente la carga y descarga de objetos de la base de datos local caché. Dado que los objetos de referencia sí, es totalmente posible tener las referencias a objetos que ya no se encuentran en memoria. Comunidad abierta ha dispuesto para hacer frente a esta contingencia, los objetos que están programadas para ser eliminado se marca como tal después de una llamada a spWM.Update () y se eliminan en la siguiente llamada a spWM.Update (). Esto da una oportunidad a la aplicación para tratar adecuadamente a estos "condenados" los objetos.

Servidores Como se señaló anteriormente, Open Comunidad evita los problemas de un servidor central por medio de un enfoque altamente distribuidas. Sin embargo, esto no significa que se ha prescindido de los servidores en total. Comunidad abierta actualmente utiliza cuatro diferentes tipos de servidores, cada uno de

12 VRML 2.0 con Java CAPÍTULO 8

los cuales realiza una función específica.

Período de sesiones de Gestión Para todo mundo (o "período de sesiones," para usar el Open Comunidad plazo), un administrador de sesiones sigue la pista de los ejércitos que forman parte de la simulación. Esto tiene un administrador de sesiones de trabajo muy ligero, ya que sólo los procesos de peticiones de hosts para conectarse o desconectarse de la sesión.

Región de Gestión Como se describe anteriormente, la Comunidad Abierta espacial utiliza un mecanismo de particionado como base para el filtrado de las actualizaciones. Se divide el mundo en varias de las regiones y hace un seguimiento de las regiones que son visibles a un usuario en particular. Cuando un usuario entra en una nueva región, es necesario informarles de otras entidades que se encuentran actualmente en esa región. Comunidad abierta maneja mediante el uso de uno o más servidores que caché que la información para facilitar el acceso. La carga de trabajo para este servidor puede ser bastante alto, pero, por supuesto, ya que muchos de estos servidores pueden ser utilizados como sean necesarios. Concebible que, cada región puede tener su propio servidor.

Beacon Gestión Comunidad abierta permite que ciertos lugares en el mundo virtual a estar marcado con un faro, para que los usuarios puedan encontrarlos fácilmente. Un faro es un poco como un favorito en un navegador Web, que permite al usuario llegar a un lugar directamente en lugar de tener que navegar por allí. Para encontrar la ubicación de una baliza por su nombre, una especie de "servidor de nombres" mecanismo es obligatorio. Al igual que con los administradores de la región, no puede haber tantos servidores de nombres, según sea necesario con el fin de ampliar a un gran número de participantes.

Bajo Speed Link Servidores El estado actual de Internet hace que muchos, muchos usuarios se conectarán mediante módems 28,8 KBaud. Esta es una grave limitación de ancho de banda. Comunidad abierta prevé para los servidores que actúan como máquinas de regular la parte de la red, sino que también se han especializado de apoyo para las máquinas que se conectan a través de ellos, utilizando las líneas de bajo ancho de banda, como se muestra en la Figura 8.4.

13 VRML 2.0 con Java CAPÍTULO 8

Figura 8.4 ¿Cómo los sistemas de bajo ancho de banda está conectado Estos servidores pueden hacer filtrado inteligente del flujo de datos, por ejemplo, pueden-por ejemplo cuando se habla de datos de ancho de banda es escaso. Una forma de hacerlo es saltarse los marcos de expresión y confiar en el software de interpolación de los datos que faltan, aunque a una menor calidad.

Clases básicas Como se mencionó anteriormente, la Comunidad utiliza Abrir una base de datos orientada a objetos enfoque. La jerarquía de clase para Open Comunidad es muy implicados, de modo que sólo una visión general se da aquí. El código siguiente muestra un subconjunto de la jerarquía de clase para Open Comunidad: sp spThing spRoot spAvatar spPOV spVisualPOV spAudioPOV spTextPOV spAudioSource spTextSource spLink spVisualDefinition spSound spText spAvatarInfo spRegion spClass La jerarquía de clase completa incluye un número de otras clases, pero la lista

14 VRML 2.0 con Java CAPÍTULO 8

de arriba es suficiente para este resumen. Ahora echemos un vistazo a cada una de estas clases en detalle.

La clase sp Un objeto compartido es representado por un público de alto nivel denominado sp clase abstracta, que contiene información básica como el objeto único de 32 bits de identificador de propietario. Desde objetos compartidos se pueden organizar en una jerarquía de árbol, cada clase derivada de sp tiene una madre soltera y un juego de niños. Transversal métodos forman parte de la clase sp.

La clase spThing Un poco spThing clase corresponde a la idea de una "entidad", que hemos introducido anteriormente en este capítulo. Contiene información sobre la ubicación, la orientación y el tamaño de una entidad, así como una referencia a la VisualDefinition que se utiliza para mostrarlo. El VisualDefinition suele ser cargados desde un archivo VRML.

La clase spRoot El spRoot clase se deriva de la clase spThing y se utiliza para representar el nivel superior de una jerarquía de la entidad. Por ejemplo, cada segmento del cuerpo (cabeza, antebrazo, muslo, etc) sería un spThing, pero sólo la raíz de una figura humana (por ejemplo, la pelvis) sería un spRoot. La clase spAvatar No todos los objetos spRoot corresponden necesariamente a los seres humanos o los agentes inteligentes. Los que sí están representados por la spAvatar clase, una subclase de spRoot que se usa para identificar "a prueba" entidades. SpAvatar la clase tiene un método que se puede llamar para averiguar si éste corresponde a un "bot" (es decir, inteligente) o para un operador humano real.

La clase spAudioSource El spAudioSource clase, derivados de spThing, se utiliza para representar una fuente de sonido posicional en el entorno virtual. Los datos pueden ser pregrabados o en vivo. Un método se proporciona para enviar datos de audio a un spAudioSource, y el Open Comunidad MUtech interfaces de audio a un render de cada cliente para que realmente reproducir el sonido.

La clase spTextSource

15 VRML 2.0 con Java CAPÍTULO 8

SpTextSource la clase es similar a la spAudioSource clase, excepto, por supuesto, que utiliza el sonido en lugar de texto. Al igual que con spAudioSource, se proporciona un método para escribir los datos de texto, que luego se mostrará en todos los clientes. Así es como el chat de texto se aplica en la Comunidad Abierta.

La clase spPOV Comunidad abierta utiliza una clase llamada spPOV, derivados de spThing, para realizar el seguimiento del punto de vista del usuario en el medio ambiente. spPOV tiene tres subclases: spVisualPOV (que determina lo que el usuario puede ver), spAudioPOV (que determina lo que puede escuchar), y spText (que determina que los mensajes de chat de texto que pueden recibir).

La clase spLink Muchos de los objetos en Open Comunidad necesidad referencia a los recursos de la red a través de una URL. Las distintas subclases de la clase spLink se utilizan para realizar un seguimiento de estos datos. Por ejemplo, la subclase spVisualDefinition de spLink se utiliza para cargar la descripción de VRML para un spThing y mantener una referencia a ella en la memoria. Otras subclases de spLink incluyen spSound, spText, spClass, y spAvatarInfo.

Más Información Lamentablemente, el espacio no nos permite proporcionar una lista detallada de todas las clases y métodos en el sistema comunitario Abierto. Si estás interesado en saber más acerca de la Comunidad Abierta y cómo funciona, consulte el Capítulo 17 en este libro para una aplicación de ejemplo. También deberá verificar el documento general y la plena especificación API, que se puede encontrar en la http://www.merl.com/opencom/.

La API de CyberSockets CyberSockets fue desarrollado por una empresa llamada Sun Interactive Negro, a fin de apoyar su CyberHub sistema multiusuario (CyberHub consistente en un servidor y uno o más clientes CyberHub). Se trata de una biblioteca, implementado en C y exigible, ya sea de C o C + +. También tiene una capa de acceso a Java, que permite que las aplicaciones Java (como el propio Cliente CyberHub) para acceder a la API de CyberSockets. Una aplicación multiusuario CyberSockets comunica a través de la API, que a su vez se comunica a través de Internet a otras aplicaciones basadas en CyberSockets y CyberHub al servidor, como se muestra en la Figura 8.5.

16 VRML 2.0 con Java CAPÍTULO 8

Figura 8.5 El modelo CyberSockets CyberSockets es similar en muchos aspectos a la Open Comunidad API. Ambos son accesibles desde Java, y ambos utilizan un reproducirse, orientado a objetos de base de datos modelo. Ambos consideran que la aplicación que tendrá a su cargo y dejar a discreción de la aplicación cuándo y con qué frecuencia para activar el control de la MUtech a fin de que pueda llevar a cabo su procesamiento. Ambos hacen disposiciones para la eliminación de los objetos de la base de datos compartida, dando a la aplicación un medio para determinar cuándo un objeto está programado para su eliminación antes de borrarlo. Ambos tienen el concepto de un avatar, con ciertas características, y ambos tienen el concepto de un objeto compartido. Sin embargo, también existen algunas diferencias importantes. Si bien los intentos de la Comunidad Abierta ocultar la red de la aplicación, CyberSockets expone que, incluso hasta el punto de hacer cosas tales como direcciones IP y puertos visibles para la aplicación y el suministro de formas de tratar con los servidores de seguridad. En ese sentido, CyberSockets es un protocolo de nivel inferior que Abiertas Comunidad. CyberSockets actualmente no hace ninguna disposición para el sonido, mientras que el Abierto Comunidad tiene soporte para el streaming de audio en tiempo real. Abrir Comunidad apoya particionamiento espacial mediante el uso de las regiones, mientras que CyberSockets usos basados en la proximidad de filtrado basado en un horizonte de visibilidad. Quizás la diferencia más importante es que CyberSockets ha incorporado en una suposición de que existe un servidor central, mientras que la Comunidad tiene un Abrir Serverless enfoque. Sin embargo, desde CyberSockets no exponer el protocolo que utiliza a través de la red, no hay nada para prevenir una futura liberación de CyberSockets el apoyo de múltiples servidores interconectados. Esta configuración sería muy similar a la utilizada por la Comunidad Abierta, en la que un servidor se conecta especializados con poco ancho de banda a los ejércitos del resto del mundo.

17 VRML 2.0 con Java CAPÍTULO 8

Arquitectura del sistema CyberSockets se construye alrededor de un objeto de base de datos, en la que cada objeto se accede mediante un asa. Algunas propiedades son comunes a todos los objetos, por ejemplo, cada objeto contiene un identificador para el período de sesiones al que pertenece, así como algunos datos de usuario arbitraria. Conceptualmente, esto no es a diferencia de la forma en que la sp clase Open Comunidad tiene ciertas propiedades que son comunes a todos los objetos compartidos. Así como una comunidad abierta la aplicación con carácter periódico la convocatoria spWM.Update () método, CyberSockets una solicitud con carácter periódico la convocatoria csNetwork () y csProcessEvent () funciones. El csNetwork () función de los servicios de la red mediante la recepción de cualquier cola de los datos entrantes y eventos para la máquina local, los eventos son posteriormente procesados por la csProcessEvent () función. CyberSockets se comunica con la aplicación mediante el envío de eventos, que la aplicación es responsable de la tramitación. Por ejemplo, cuando llega un nuevo avatar en el mundo, un csEvtAvatarNew caso se envía a la aplicación. La aplicación puede registrar manejadores de eventos es lo que interesa y puede manejarlos sin embargo éste elija. Abrir como Comunidad, CyberSockets necesita algún mecanismo por el cual notificará a la aplicación de un objeto que está siendo eliminado. CyberSockets se encarga de este PreDelete mediante el envío de un evento de un objeto a la aplicación. Muchos CyberSockets funciones implican el envío de datos al servidor y recibir datos de ella. Por ejemplo, para salir de un grupo, la aplicación que llame a la csGrpSndLeave (), que envía un mensaje al servidor (y otros miembros del grupo) a tal efecto. Para conseguir la posición más reciente de un avatar, la solicitud de llamada csAvatarReqPosition (), y posteriormente recibirá una respuesta en caso csEvtAvatarPosition. La razón de la separación de la solicitud de la respuesta CyberSockets es que está diseñado para funcionar en un entorno de subprocesamiento único, y usted no desea que el sistema para bloquear a la espera de una respuesta del servidor.

Los Tipos de objetos Así como hay una serie de clases abiertas en la Comunidad, CyberSockets define un número de diferentes tipos de objetos. Cada objeto tiene un conjunto

18 VRML 2.0 con Java CAPÍTULO 8

de funciones relacionadas con él, que son en muchos aspectos análoga a los métodos disponibles en los objetos en Open Comunidad. Tipo de objeto de la reunión En CyberSockets, un mundo que se denomina un período de sesiones. Una sesión tiene varias propiedades asociadas con ella, tales como el servidor que está siendo utilizada para el período de sesiones y el nombre de usuario y contraseña que el usuario utiliza para conectarse a ese período de sesiones. Dentro de un período de sesiones no puede ser cualquier número de escenas, una de las cuales es el panorama actual para el cliente. Cada escena tiene un nombre de escena y una lista de los usuarios en esa escena. Cuando el usuario mueve su avatar, que envían su nueva posición y la orientación para el período de sesiones. También pueden actualizar sus atributos avatar en el servidor. La aplicación también envía mensajes de sesión cuando el usuario entra o sale de una escena.

Tipo de objeto el Avatar Un avatar tiene una serie de propiedades, como un alias y una definición visual (generalmente en VRML), así como algunos de información pública (similar a la de Open spAvatarInfo Comunidad). Además, cada avatar tiene una posición y orientación. CyberSockets enviará los eventos de la aplicación cuando se llega a un avatar de la escena, entra en el horizonte del usuario, el usuario sale del horizonte, o sale de la escena. La solicitud puede fijar el número máximo de los avatares que se permite en el horizonte del usuario en un momento dado.

El Grupo Tipo de objeto Un grupo se utiliza para limitar el alcance de una conversación de chat de texto. Cuando el usuario está en un grupo particular, todo tipo que se envía a los demás miembros del grupo, y viceversa. Cada grupo tiene un tema (como una especie de tema en un canal de IRC) y una descripción. Hay métodos para iniciar un nuevo grupo, uniéndose a una ya existente, y la salida de un grupo, así como los evidentes métodos para enviar y recibir texto.

Al Mecanismo de Tipo de objeto Además de chat de grupo, es posible comunicar "uno a uno" mediante CyberSockets. A los pares es básicamente una referencia a otro usuario en el

19 VRML 2.0 con Java CAPÍTULO 8

sistema; se dan métodos para enviar y recibir mensajes de texto con un compañero, así como para transferir los objetos etiquetados (que se describen a continuación). También hay métodos para llamar a alguien y les invitó a ser un compañero, en respuesta a una invitación de ese tipo, y colgar en el puesto.

Tipo de objeto de la etiqueta Una etiqueta es una colección de objetos con nombre de atributos. Cada atributo tiene un nombre (o "tag") y un valor, por ejemplo, si se envía un valor de color (por ejemplo, para hacer tu avatar rubor) que pueda tener una etiqueta de "faceColor" y un valor que consta de tres de punto flotante números que el rojo, verde y azul, los valores de los componentes del color. Etiquetado de objetos pueden ser enviados de un usuario a otro como una forma de intercambio de pequeñas cantidades de datos, que no son adecuados para la transferencia de archivos grandes de datos o de otros.

El Shared Object Tipo A Shared Object es una estructura de datos que contengan campos que se comparten a través de la red. Ellos son el único elemento de CyberSockets que se corresponde directamente con VRML. Próximos eventos en el servidor debe de ser enviado (por ejemplo, a través de la interfaz de los mundos de vida que se describe en el capítulo 7) a la correspondiente eventOuts en el nodo de VRML. Del mismo modo, los eventos que llegan a la VRML eventIns nodo debe ser enviada a la red. Existe una estrecha correspondencia entre un Shared Object en CyberSockets y un SharedObject Vida en el universo propuesta. Esto no es sorprendente, ya que Domingo Negro es una de las tres empresas que creó el universo de vida propuesta.

Más Información Una vez más, el espacio no permite una descripción detallada de todas las diferentes estructuras de datos y funciones que componen el CyberSockets API. Más información acerca de la API de CyberSockets se puede encontrar en el sitio interactivo Domingo Negro, http://www.blacksun.com, en la sección de desarrolladores.

20 VRML 2.0 con Java CAPÍTULO 8