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