Universidad Autónoma Metropolitana Unidad Iztapalapa

División de Ciencias Básicas e Ingeniería

Transporte de Voz Sobre Protocolo TCP/IP y su Implementación con JMF.

Tesis que presenta el alumno

Marco Ulises López Díaz 94319149

Para la obtención del grado de

Ingeniero en Electrónica

.kl. Asesor M. en C. Miguel ' hge l Gutiérrez Galindo

Junio de 2001

Transporte de voz

sobre protocolo

TCPIIP,,, Implementación

con JMF.

Marco Ulises López Proyecto Terminal I

Díaz

Bases Teóricas

Transporte de Voz sobre Protocolo TCP/IP y su Implementación con JMF.

Bases Teóricas

Marco Ulises López Díaz

Universidad Autónoma Metropolitana Unidad Iztapalapa

División de Ciencias Básicas e Ingeniería Departamento de Ingeniería Eléctrica

Licenciatura en Ingenieria Electrónica Area de concentración: Comunicaciones

Proyecto Terminal I

México, D.F. Enero de 200 1

Prefacio

2.2 5 93.0 El presente) documento contempla la primera de dos partes de la mvestlgaclon acerca de la implementación del transporte -de voz sobre el conjunto de protocolos TCP/IP utilizando el lenguaje Java.

Este documento llamado “Bases Teóricas”, nos acerca hacia los conocimientos mínimos necesarios para poder entender como trabaja la aplicación “Transporte de voz...’’ que se desarrolla como segunda parte de esta investigación con el título “Implementación”.

Esta implementación sobre el transporte de voz, se utilizará en el desarrollo de la multimedia del proyecto “Educación a Distancia” que se desarrollará en el Laboratorio de Ingeniería de Software de esta Universidad; el desarrollo e implementación de este proyecto, permitirá en esa aplicación, que un profesor tenga una presencia virtual, y se comunique con los alumnos usando la voz a través de Internet,

A fin de lograr reunir un esquema completo de los temas en los que se íündamenta este proyecto, se hace referencia a temas como “Mecanismos de Transporte”, “Sistemas Abiertos”, “Arquitectura Cliente/Servidor”, “Sockets”, “Protocolos” y “Tecnología de Objetos”, los cuales, permiten que cualquier persona interesada en este proyecto pueda, seguir paso a paso el documento “Implementación”, sin necesidad de detenerse por falta de conocimiento o entendimiento en algún termino usado en esa parte.

Recomiendo leer varias veces los apartados “Arquitectura Cliente/Servidor” y “Tecnología de Objetos”, los cuales considero son los más importantes en este documento y en todo el proyecto; s i n quitarle a alguno de los otros temas tratados su correspondiente mérito.

La selección de los protocolos TCP/IP para el desarrollo de este proyecto, se debe al hecho importante de ser el conjunto de protocolos en el que se basa la Internet actualmente. Se presenta una descripción general de estos protocolos, solo con el fin de sentar bases teóricas mínimas en su conocimiento.

El lenguaje Java se escogió debido a que cuenta con una arquitectura amigable para desarrollar aplicaciones para Internet, además de contar con una interfaz nueva llamada Java Media Framework (JMF), la cual se tomó como base de toda nuestra implementación.

Este texto contiene además, algunos ejemplos de aplicaciones en Java, como el conocido “HelloWorld” comúnmente utilizado, para entender conceptos como el Applet y el desarrollo de un formulario para el entendimiento del concepto Servlet.

Al h a 1 del documento, se presenta una dehición utilizada en el JMF, de lo que debemos entender por medios que dependen del tiempo, que será un termino bastante utilizado en la segunda parte, además, se presenta el modelo general de cual será el proceso de estos medios y los tipos de formatos que soporta esa arquitectura.

I

V

Anteproyecto

Con el uso de la herramienta de desarrollo orientado a objetos “Java” y sus respectivas interfaces, implementaremos la arquitectura descrita en la interfaz Java Media Framework (JMF), con la cual podremos manipular, procesar, transmitir, recibir y presentar la voz en un ambiente orientado a objetos. Tomando ventajas de la plataforma Java, JMF cumple con la promesa de “Write Once, Run Anyware”, que permitirá que futuros desarrollos se implementen con esta arquitectura.

El Proyecto Terminal en su conjunto, pretende sentar las bases para que, cualquier persona interesada en el desarrollo del tratado de medios, tenga una referencia clara y en español de las herramientas e interfaces para el desarrollo e implementación de esta tecnología.

Contenido

Prefacio iv

Organización y Cobertura iv

Anteproyecto v

Contenido vi

Presentación 1

Introducción 3

Mecanismos de Envío de Información 3 Sistemas Abiertos 4 Arquitectura Cliente/Servidor 5

Socket 7 Protocolos 8

TCP / IP (Transmission Control Protocol / Internet Protocol) 8 9 TCP (Transfer Control Protocol)

IP (Internet Protocol) 10 1Pv4 (Internet Protocol Ver. 4) IPv6 (Internet Protocol Ver. 6 :

UDP (User Datagram Protocol)

11 IPng) 13

15

RTP (Real Time Protocol) 16

RTCP (Real Time Control Protocol) 18 Aplicaciones de RTP y RTCP 19

VoIP (Voice On IP) 19

Tecnología de objetos 22

Java 24 Applets 26

Ciclo de vida de un Applet 28 Etiqueta APPLET 30 Ejecución Multihilo (multihread) en Applet. 3 1

¿Por qué los Serlvets son mejores que los CGI’s? 33 Aplicaciones de los Servlets 34 Instalación del Java Servlet Development KIT (JSDK 2.0) 35 Ciclo de de vida del Servlet 39

Serviets 33

Java Media Framework API Guide 40

Medios que dependen del tiempo 40 Modelo de Referencia 41

. Tipos de Contenido y Formatos 42

8

vii

Arquitectura JMF 44

Modelo de Tiempo 44 Manejadores (Managers) 45

Conclusiones 47

Bibliografía 48

Indice de Figuras 49

Indice Alfabético 50

Presentación.

Con el desarrollo de la civilización y de las lenguas escritas surgió también la necesidad de comunicarse a distancia de forma regular, en aquellos días, solo con el fin de facilitar el comercio. El uso del papiro, el pergamino, y el papel, amplió las posibilidades de comunicación y condujo a cambios radicales en la forma de vivir de los pueblos, estos cambios contribuyeron a la aparición de un mayor individualismo, del racionalismo, de la investigación científica y de las literaturas nacionales.

De los diferentes tipos de servicios de comunicación de la antigiledad, el más notable file el sistema de relevos o servicios postales, como lo conocemos actualmente. Los sistemas postales modernos siguieron creciendo con la aparición del ferrocarril, los vehículos de motor, los aviones y otros medios de transporte. Sin embargo, a lo largo de los siglos siempre se han buscado medios de comunicación a larga distancia que fueran más rápidos que los convencionales. Con el descubrimiento de la electricidad desde el siglo X V I I I , se comenzó a buscar la forma de utilizar las señales eléctricas en la transmisión rápida de mensajes a distancia.

A pesar de que la telegrafía supuso un gran avance en la comunicación a distancia, los primeros sistemas telegráficos sólo permitían enviar mensajes letra a letra. Por esta razón se seguía p2: &%?,&

buscando algún medio de comunicación eléctrica de voz, surgiendo así los sistemas telefónicos que, por su parte, establecieron una mejor forma de comunicarse. Pero existía en aquellos días un límite al utilizar el cable como soporte fisico para la transmisión de la voz, las investigaciones científicas en el campo del electromagnetismo indicaban que podían existir q :; otras posibilidades. f:, ('1

$7;2

I ' L !

El descubrimiento del uso de ondas de radofi-ecuencia utilizadas para los sistemas de mensajería y de noticias, volvió a revolucionar el mundo de las comunicaciones; para 1925 ya hcionaban 600 emisoras de radio en todo el mundo y el número de emisoras de televisión pasó de 6 en 1946 a 1,362 en 1988. En la actualidad, casi todos los hogares de los países desarrollados disponen de radio y televisión.

Desde la aparición de las primeras computadoras hgitales en la década de 1940, éstas se han introducido en los países desarrollados en prácticamente todas las áreas de la sociedad (industrias, negocios, hospitales, escuelas, transportes, hogares, comercios, etc.). El ritmo de adopción de nuevas tecnologías de la información (TI) ha sido muy rápido, mucho más que el de otras tecnologías revolucionarias del pasado. A los 25 años de su invención, el microprocesador se había convertido en algo corriente en casi todos los lugares de trabajo y en muchos hogares; no sólo está presente en los computadores, sino en una inmensa variedad de otros dispositivos, desde teléfonos o televisores hasta lavadoras o juguetes infantiles.

Las nuevas tecnologías de información basadas en la microelectrónica, junto con otras innovaciones, como los discos ópticos o la fibra óptica por nombrar solo algunos, permiten enormes aumentos de potencia (y reducciones de costos) en toda clase de actividades de procesado de información, es decir, la generación, almacenamiento, transmisión, manipul&ión y visualización de información, que incluye datos numéricos y diversos medios como texto, sonido o video.

Al hablar de estos medios hablamos de la transmisión y recepción de ideas con una rapidez inimaginable, que en los últimos 150 años y en especial en las dos últimas décadas ha sido motivo de una inminente revolución de la información. Mediante la utilización de las redes informáticas y los dspositivos auxiliares, el usuario de una computadora puede transmitir datos con gran velocidad al hacer uso de esta nueva tecnología.

2

A pesar de que la informática y las telecomunicaciones eran en el pasado sectores bastante diferenciados, que implicaban tecnologías distintas. En la actualidad, estos sectores han convergido alrededor de algunas actividades clave, como el uso de Internet. Los actuales dispositivos informáticos y de telecomunicaciones manejan datos en forma digital empleando las mismas Gcnicas básicas. Estos datos pueden ser compartidos por muchos dispositivos y procesarse en todos ellos y emplearse en una amplia gama de actividades de procesado de información.

La reducción de l o s tiempos de transmisión de la mformación a &stancia y de acceso a la información ha supuesto uno de los retos esenciales de nuestra sociedad. La Internet permite una interconexión en particular, de carácter planetario y abierto al público, que reduce en gran medida el retraso de la infornlación, al conectar redes informáticas de organismos oficiales, educativos y empresariales, todo en un mismo ente informático. La revolución de las telecomunicaciones y de la transmisión de datos ha empujado al mundo hacia un nuevo concepto: la “aldea global”.

La Internet marca las postrimerias del Siglo XX con un tinte de revolución comunicativa sin precedentes, tiene ante sí un futuro abierto e imprevisible, es una precursora de la llamada “superautopista de la información”. El contenido disponible en la Internet hace más fácil encontrar cualquier tipo de información. Las nuevas aplicaciones permiten incluso ya realizar transacciones económicas de forma segura y proporcionan nuevas oportunidades para el comercio. Actualmente, la transmisión de medios a través de radio, televisión y prensa, se entremezclan entre sí dentro de la Internet para brindar sus medios a quien lo quiera y en el momento que quiera.

A principios de 1996 estaban conectadas a Internet más de 25 millones de computadoras en más de 180 países, para 1998 existían ya 300 millones ...

... hoy existen mas de 600 millones de ordenadores en el mundo y la cifra aumenta con grado exponencial año tras año.

Introducción.

Mecanismos de Envio de Información.

El método con que se realiza el enrutamiento o encaminamiento de la información, en una red de telecomunicaciones (Internet por ejemplo), desde su origen hasta su destino ofrece diversos criterios para clasificar a las redes, separándolas en dos grandes grupos:

o Redes No Conmutadas o de Difisión o Redes Conmutadas

En las Redes de Difisión, existe solo un medio comiln compartido para transmitir la información desde la fuente hasta el destino, un ejemplo típico es la comunicación vía satélite, en el que la estación terrena envía una señal al satélite y este radia una señal a lo largo y ancho de una región utilizándose el espacio libre como imico camino para enviar y recibir la información.

Las Redes Conmutadas por su parte, requieren un mecanismo de encaminamiento para llevar la información de una fuente hacia un destino, es decir, dichos mecanismos requieren de tomar una decisión para escoger entre varias rutas para llegar a su destino (ver Figura 1).

Figura I . Red Conmutada

A las redes conmutadas podemos a su vez, clasificarlas en tres subgrupos:

O Conmutación de Circuitos o Conmutación de Mensajes O Conmutación de Paquetes

Las primeras identifican una trayectoria dedicada, es decir, establecen un circuito físico dedicado entre dos estaciones, en cada enlace físico se establece un canal que se reserva para la conexión y por el tiempo que esta dure, un ejemplo que cae dentro de esta clasificación es el sistema telefónico ordinario.

4

En la Conmutación de Mensajes, no es necesario establecer una trayectoria dedicada, el enlace entre dos nodos o estaciones se utiliza solamente durante el tiempo en que un mensaje transita por 61 y se libera cuando se termina de transmitir, lo que sucede por ejemplo cuando enviamos un correo electrónico o recibimos un mensaje con un radiolocalizador.

Por su parte, la Conmutación de Paquetes, es un intento por combinar lo mejor de las técnicas de conmutación de mensajes y conmutación de circuitos; la principal diferencia, -a pesar de que es muy parecida a la conmutación de mensajes,- es que, la longitud de las unidades de datos que pueden ser manejadas por la red, esta limitada, en consecuencia los mensajes de mayor longitud que la establecida por la estación o protocolo deben ser divididos en unidades de datos mas pequeños. La secuencia de comunicación de los mensajes puede manejarse de dos formas:

o Circuitos virtuales o Datagramas.

En los circuitos virtuales se establece una conexión lógica antes de que cualquier paquete se envíe, como lo que sucede cuando escuchamos el timbre de llamada entrante con un teléfono celÚlar; una vez establecido el camino lógico se coloca en cada paquete, además de los datos, un identifícador de la conexión, para saber hacia donde dirigirse por lo cual no se requiere de decisiones de enrutamiento.

En los datagramas, cada paquetes se trata independientemente, de la misma forma que un mensaje se trata en las redes de conmutación de mensajes, de modo que cada paquete sigue una ruta diferente de acuerdo a las condiciones de carga de la red y a las decisiones de enrutamiento de los nodos o estaciones que la componen. Al final, la estación o protocolo que recibe los paquetes, se encarga de ordenarlos en la secuencia adecuada y eliminar los que arriben con dafio, en algunos casos inclusive, solicitar de nuevo alguno de estos.

Sistemas abiertos

En el ámbito de las Tecnologías de la Información y las Comunicaciones aparecen Constantemente nuevos conceptos y términos que están a menudo asociados con nuevas técnicas o formas de uso de esas tecnologías. En esta definición se alude a sistemas informáticos cuya arquitectura permite una interconexión y una distribución ficiles.

La tecnología, por su parte, desarrolla sus productos cada vez con mayor velocidad, ofreciendo nuevas posibilidades y mejoras, pero que muchas veces no son compatibles con las tecnologías y sistemas ya instalados.

De aquí surge la necesidad de poder acceder a los nuevos sistemas y compartir información entre entomos diferentes o entre usuarios. Pero todo ello favorece la competencia dando lugar a mejores precios para los posibles usuarios de estos sistemas.

Pam dar respuesta a todos estos problemas aparece el concepto de Sistema Abierto.

Según [SO’ “un sistema abierto es todo sistema informático capaz de interconectarse con otros de acuerdo con unas normas establecidas”. Por su parte !a Comisión de las Comunidades Europeas establece que: “Los Sistemas Abiertos son aquellos sistemas y componentes que pueden ser especificados y adquiridos de fuentes distintas en un mercado competitivo. Las especifsaciones de los Sistemas Abiertos deben ser controladas por organizaciones internacionales de normalización o, al menos, por un especificador tan independiente como s e a posible con un amplio grado de aceptackh en el mercado. Una especificación de Sistema Abierto no debe ser propiedad de un Único suministrador y debe estar disponible sin coste”.

En la práctica, el concepto de sistema abierto se traduce m desvincular todos los componentes de un sistema y utilizar estructuras análogas en todos los demás. Esto conlleva una mezcla de normas (que indican a los fabriemtes lo que debefían hacer) y de asociaciones (grupos de entidades afines que les ayudan a realizarlo).

Todas las definiciones anteriores coinciden en que un Sistema Abierto debe cumplir las características de:

Interoperabilidnd: posibilidad de enlazar computadoras y sistemas diferentes para trabajar conjuntamente dando la sensación de ser un Único sistema.

Portcrbilidnd: posibilidad de que una misma aplicación pueda funcionar en distintas plataformas fisicas.

Crecimiento o Escalabilidaci: posibilidad de aumentar la potencia de la aplicación con sólo aumentar la potencia de la plataforma fisica en la que se ejecuta.

El efecto final es que dos o más sistemas sean capaces de “hablar” entre sí.

Hoy en día, este nuevo concepto se encuentra muy anlpliamente aplicado en los ambientes de las computadoras personales y estaciones de trabajo que presentan cada vez mayores prestaciones gráficas y de comunicación entre máquinas. Aparece también, en los procesos y aplicaciones cooperativas en las que es posible la intervención de varios sistemas o equipos. En este sentido se relaciona con l o s ccmceptos de Cliente/Servidor y de programación orientada a objetos.

El objetivo último de todo el esherzo invertido en los sistemas abiertos consiste en que cualquiera pueda adquirir eomputadoras de diferentes fabricantes, las cdcque donde quiera, utilice conexiones para enlazarlas entre sí y las haga fimcionar como una máquina compuesta capaz de sacar provecho de esas conexiones.

Arquitectura Cliente/Servidor

ClientelServidor, es una filosofia o paradigma que divide las aplicaciones que se comunican entre sí en dos categorías, dependiendo de si, la aplicación se queda en espera de conexiones (SERVIDOR), o bien si es quien inicia las conexiones (CLIENTE). En vez de construir sistemas informáticos cum0 elementos rnonolíticos, sistemas que solo tengan la €unción principal general de recibir o enviar datos, la arquitectura ClientelServidor propone una estructura de los sistemas informáticos que se traduce en una bien estructurada comunicación, es decir, una conexión optima que permite la sincronización de procesos. Los detalles de la realización van desde los planteamientos más sencillos como el errviar y recibir un caracter, hasta la posibilidad real de manejar distintas computadoras de modo uniforme.

1 ISO: International Standard Organization

6

En este paradigma, los usuarios finales invocan aplicaciones Clientes cuando utilizan un servicio de red. Cada vez que se ejecuta una aplicación Cliente, esta conecta con el Servidor, le envía una solicitud de servicio y espera la respuesta o resultados de dicho servicio. El proceso Cliente es el encargado de llevar a cabo la interacción con el usuario y de mostrar los resultados de las peticiones de servicios. En la mayoría de las ocasiones los Clientes son más fáciles de diseñar que los Servidores, y no suelen precisar privilegios especiales del sistema para poder hc ionar .

Un Servidor es un programa que espera peticiones de servicios por parte de un Cliente. El Servidor recibe la petición de un Cliente, ejecuta el servicio solicitado y retorna los resultados al Cliente. No existe una interacción directa entre el usuario y el Servidor, ya que este es un programa que ejecuta las acciones, y de la interacción con el usuario, ya se encarga la aplicación Cliente.

Cuando es un Cliente el que pide el servicio, no hay problema en que el Servidor le de respuesta, pero cuando hay más de un Cliente, o mejor dicho, son muchos los Clientes que desean interactuar con el Servidor al mismo tiempo se produce una congestión y lógicamente, se debe implementar una política de orden para poder atenderlos a todos. Pero aún así sería engorroso el atenderlos de a uno, por lo tanto se debe implementar una forma en la que el Servidor pueda ser capaz de satisfacer las peticiones de sus clientes conectados a él (comúnmente llamado “On Line”). Para ello se utiliza un proceso padre, que crea uno o varios procesos hijos, donde estos úitimos tienen las mismas características del padre, y luego cada uno de estos procesos se conectan con las peticiones de los distintos Clientes. De esta manera cada Cliente tendrá su respuesta en un menor tiempo, sin necesidad de esperar que se atiendan otros Clientes antes que él.

Esta arquitectura se puede clasificar en cinco niveles, según las funciones que asumen el Cliente y el Servidor, ta l y como se puede ver en el siguiente diagrama (ver Figura 2):

Figura 2. Arquitectura Cliente/Servidor

Los procesos Clientes y Servidores han de seguir un protocolo de comunicaciones que definan lo siguiente:

o Cómo se codifican las solicitudes. O Cómo se sincronizan entre sí los procesos

7

Los Clientes y Servidores han de estar de acuerdo en cómo se escriben los mensajes, en qué orden van los posibles parimetros de la solicitud, cuántos bytes ocupan, etc. . La forma de sincronización nos dice si el Cliente puede seguir adelante justo después de enviar la solicitud o por el contrario tiene que esperar a que el Servidor le envíe una respuesta.

Socket

Un Socket, es una forma de conectar dos procesos, de manera que una vez que el Cliente pida una solicitud, el Servidor creará una replica que se conecte a través de este mecanismo con el Cliente, para "escuchar" o atender dcha solicitud, y darle una respuesta correspondente. Los sockets proporcionan una conexión segura, que es lo primordial para todo sistema basado en la comunicación, o mejor dicho, interacción entre dos o más procesos.

La comunicación entre procesos a través de los sockets se basa en la filosofía ClienteKervidor, en el cual un proceso actuará como proceso Servidor, creando un socket cuyo nombre conocerá al proceso Cliente, el cual podrá "hablar" con el proceso Servidor a través de la conexión que genera el socket.

Si se hace la comparación, un socket es al sistema de comunicación entre computadores, como un buzón o un teléfono es al sistema de comunicación entre personas: un punto de comunicación entre dos agentes @rocesos o personas respectivamente), por el cual se puede recibir o trasmitir información. Esta característica de interconectividad entre máquinas hace que el concepto de socket sea de gran utilidad. Esta interfaz de comunicaciones es una de las contribuciones de la Uniuersidad Berkeley al sistema UNIX, utilizamos pues la referencia teórica en este apartado, para entender el hcionamiento de interconectividad basado en sockets. Hoy en día, casi tndos los sistemas operativos integran esta interfaz para su uso como parte de su distribución.

El mecanismo de comunicación entre sockets, está compuesto por los siguientes pasos:

l . El proceso Servdor crea un socket con nombre, y espera la conexión. 2. El proceso Cliente crea un socket s in nombre. 3. El procesa Cliente realiza una petxión de conexión al socket Servidor. 4. El Cliente realiza la conexión a través de un socket, mientras el proceso Servidor mantiene el socket Servidor original con nombre.

Una parte muy importante que se debe tener en cuenta, es que cuando se crea el Servidor, &e deberá h c i o n a r indefinidamente o por largos períodos de tiempa, es decir, cuando termine de atender una conexión debe volver a esperar y procesar una segunda. Así que, cuando por primera vez el Servidor entra al ciclo que permite la conexión con un Cliente, tomará la primera solicitud de la conexión de la cola, la procesará, y finalmente cerrará el socket de comunicación recién creado. Si en la cola no llegara a haber ninguna solicitud de conexión, el Servidor se bloqueará en este punto hasta que llegue otra solicitud.

Hemos pues, entendido que b s sockets son puntos o mecanismos de comunicacion entre procesos que permiten que un proceso hable (emita o reciba información) con otro proceso, incluso estando estos procesos en distintas máquinas.

En Java los procesos Cliente/Servidor se conectan utilizando threads, lo cual significa que se crean hilos o nuevos procesos l o s cuales comparten Fecursos. La cumunicacih de threads es un típico modelo Cliente/Servidor. Un thread produce una salida, que otro thread usa (consume), sea lo que sea esa s a l i d a . M a s adelante en el apartado "Java" mencionaremos la defkición de Thread y algunos ejemplos de aplicación.

a

8

Protocolos

En el problema de desarrollar un sistema abierto, se estableció la diferenciación de las tareas que deben soportarse para la operación de éste. En cada maquina de la red se definen módulos o entidades funcionales que se encargan de completar las tareas reconocidas para asegurar que la red conserve su estándar de sistema abierto.

En forma esquemática podemos hablar de una comunicación vertical entre los módulos de una misma maquina, para contrastarla con la comunicación horizontal entre los módulos de un mismo tipo ubicados en maquinas distintas.

NIVEL DE APLICACIóN 4

NIVEL DE TRANSPORTE

NIVEL DE INTERNET

NIVEL DE RED

NIVEL FÍSICO v

Figura 3. Módulos de una misma máquina.

Comunicación Vertical entre niveles o capas.

Es deseable que este esquema vertical sea independiente y que reaccione mediante secuencias normalizadas de datos a través de puntos de interfaz que definan el intercambio de servicios, sin atender a su construcción interna.

Estos módulos de un mismo tipo, residentes en maquinas distintas, cooperan para ofrecer un servicio distribuido. Las reglas que definen esta cooperación son los llamados protocolos.

TCP/IP : Transmission Control Protocol / Internet Protocol

El Protocolo de Internet ( IP: Internet Protocol ) y el Protocolo de Control de Transmisión (TCP: Transmission Control Protocol) fberon desarrollados inicialmente en 1973 por el informáttico estadounidense Vinton Cerf como parte de un proyecto dirigido por el ingeniero estadounidense Robert Kahn y patrocinado por la Agencia de Programas Avanzados de Investigación (ARPA, siglas en inglés) del Departamento Estadounidense de Defensa. Internet comenzó siendo una red informática de ARPA (llamada Arpanet) que conectaba redes de computadoras de varias universidades y laboratorios de investigación en Estados Unidos.

TCP/IP no es un Único protocolo, sino que en realidad, lo que se conoce con este nombre es un conjunto de protocolos. Se desarrolló originalmente para la comunicación de computadoras con sistema operativo UNIX, pero ahora está hsponible para establecer una conexión a través de Internet usando cualquier sistema operativo. Los dos protocolos más importantes de este conjunto son el TCP y el IP, que son los que dan nombre al conjunto. La relación de los protocolos TCP/IP es jerárquica.

9

La organización de las fhciones de los protocolos de la arquitectura TCP/IP se pueden mapear como en OSI’ en cinco niueks o capas. (ver F u p a 3)

- Aplicación: Se corresponde con los niveles OS1 de aplicación, presentación y sesión. Aquí se incluyen protocolos destinados a proporcionar servicios, tales como correo electrónico (SMTP), transferencia de ficheros (FTP), conexión remota (.TELNET) y otros más recientes como el protocolo HTTP (Hypertext Transfer Protocol)

- Transporte: Coincide con el nivel de transporte del modelo OSL Los protocolos de este nivel, tales como TCP y UDP, se encargan de manejar los datos y proporcionar la fiabilidad necesaria en el transporte de los mismos.

- Internet: Es el nivel de red del modelo OSI. Incluye al protocolo IP, que se encarga de enviar los paquetes de información a sus destinos correspondientes. Es utilizado con esta finalidad por los protocolos del nivel de transporte.

- Red: Es la interfaz de la red real. TCP/IP no especifica ningún protocolo concreto, así es que corre por las interfjaces conocidas, como por ejemplo: 802.2, CSMNCD, X.25, etc. .

- Físico: Análogo al nivel físico del OSI.

TCP: Transmission Control Protocol

Es un protocolo diseñado para la comunicación de datos con un alto grado de control de error. Los programas que utilizan TCP tienen un servicio orientado a conexión entre los programas llamados y los que llaman, chequeo de errores, control de flujo y capacidad de interrupción. El protocolo TCP proporciona un servicio de comunicación que forma un circuito, es decir, que el flujo de datos entre el origen y el destino parece que sea continuo. TCP proporciona un circuito virtual el cual es llamado una conexión. Su operación en general, es retransmitir un paquete de datos cuando este se perdió o se corrompib en el trayecto. Su formato básico se muestra en la Figura 4.

Figura 4. Formato del mensaje TCP

2 OSI: Modelo de caps de propuesto por I S 0 (International Standard Ormat ion) para la Interconexibn de Sistemas Abiertos. (OS1 : Open System Interchange)

10

IP : Internet Protocol

El Protocolo de Internet UP) es el soporte lógico básico, empleado para controlar el sistema de interconexión de la red. Este protocolo especifica cómo las computadoras o sistemas de puerta mejor conocidos como gateways, encaminan la información desde el equipo emisor hasta el equipo receptor.

IP define el modo en que los datos se dividen en bloques, denominados paquetes, y establece el camino que recorre cada paquete hasta su destino.

El pr$ocolo IP trabaja de la siguiente manera: la capa de transporte toma los mensajes y los divide en datagramas, de hasta 64Kbytes cada uno. Cada datagrama se transmite a través de la red, posiblemente fragmentándose en unidades más pequeñas, durante su recorrido normal. Al final, cuando todas las piezas llegan a la miquina destinataria, la capa de transporte los reensambla para así reconstruir el mensaje original. Un datagrama IP consta de una parte de cabecera y una parte de texto. La cabecera tiene una parte fija de 20 bytes y una parte opcional de longitud variable. En la figura 5 se muestra la estructura de un datagararna IP.

bersión bong. cab pipo de servicio bongitud total 1 bdentifícación Plags pffset fragmento biempo de vida protocolo PCS cabecera birección IP fuente birección IP destino

belleno

Figura 5. Estructura de un datagrama IP

El campo Versión indica la versión del protocolo al que pertenece cada uno de los datagramas. Mediante la inclusión de la versión en cada datagrama, no se excluye la posibilidad de modificar los protocolos mientras la red se encuentre en operación. El campo Opciones se utiliza para fines de seguridad, encaminamiento fuente, informe de errores, depuración, sellado de tiempo, así como otro tipo de información. Esto, básicamente, proporciona un escape para permitir que la versiones subsiguientes de los protocolos incluyan información que actualmente no está presente en el diseño original. También, para permitir que los experimentadores trabajen con nuevas ideas y para evitar, la asignación de bits de cabecera a información que muy rara vez se necesita.

Debido a que la longitud de la cabecera no es constante, un campo de la cabecera (Long. cab) permite que se indique la longitud que tiene la cabecera en palabras de 32 bits. El valor mínimo es de 5. Tamaño: 4 bit.

El campo Tipo de Servicio le permite al equipo anfitrión (host) indicarle a la subred el tipo de servicio que desea. Es posible tener varias combinaciones con respecto a la seguridad y la velocidad. Para voz digitalizada, por ejemplo, es más importante la entrega rápida que corregir errores de transmisión. En tanto que, para la transferencia de archivos, resulta más importante tener una transmisión fiable que entrega rápida. También, es posible tener algunas otras combinaciones, desde un tráfico rutinario, hasta una anulación instantánea. Tamaíio: 8 bit.

La Longitud Total incluye todo lo que se encuentra en el datagrama tanto la cabecera como los datos. La máxima longitud es de 65,536 bytes. Tamaio: 16 bit.

IPv4 : Internet Protocol Ver. 4

El Protocolo IP proporciona un sistema de distribución que es poco fiable incluso con una base sólida. El protocolo IP especifica que la unidad básica de transferencia de datos en el TCP/IP es el datagrama. Los datagramas pueden estar retrasados, perdidos, duplicados, enviados en una secuencia incorrecta o fragmentados intencionadamente para pemlitir que un nodo con un buffer limitado pueda almacenar y procesar todo el datagrama. Es la responsabilidad del protocolo IP reensamblar los fragmentos del datagrama en el orden correcto. En algunas situaciones de error los datagramas son descartados sin mostrar ningún mensaje mientras que en otras situaciones los mensajes de error son recibidos por la máquina origen.

El protocolo IP también define cual será la ruta inicial por la que serán mandados los datos. Cuando los datagramas viajan de unos equipos a otros, es posible que atraviesen diferentes tipos de redes. El tamaño máximo de estos paquetes de datos puede variar de una red a otra, dependiendo del medio fisico que se emplee para s u transmisión. A este tamaño máximo se le denomina MTU (Maximum Transmission Unit), y ninguna red puede transmitir un paquete de tamaño mayor a esta MTU. El datagrama consiste en una cabecera y datos. ( Figura 5)

Longitud de Ir Cabecera Este campo ocupa 4 bits, y representa el número de octetos (bytes) de la cabecera dividido por cuatro, lo que hace que este sea el número de grupos de 4 octetos en la cabecera.

El campo versión ocupa 4 bits. Este campo hace que diferentes versiones del protocolo IP puedan operar en la Internet. En este caso se trata de la versión 4.

Version

Direccionnmiento IPvl Las direcciones IP hacen que el envío de datos entre computadoras se haga de forma eficaz, de un modo similar al que se utilizan los números de teléfono. Para identificar cada máquina en la Internet, se le asigna un número denominado dirección Internet o dirección IP. Este número es asignado de tal forma que se consigue una gran eficiencia al encaminar paquetes, ya que codifica la información de la red en la que está conectado, además de la identificación del host en concreto.

Cada drección Internet tiene una longitud fija de 32 bits. Los bits de las direcciones IP de todos los host de una red determinada comparten un prefijo común. Conceptualmente, cada dirección IP es una pareja formada por identidad de red-identidad de host, donde la identidad de red identifica a la red, e identidad de host, a un host determinado dentro de esa red.

Para que exista una flexibilidad en la asignación de direcciones, existen tres formatos básicos de representación de direcciones. La elección de uno de estos formatos dependerá del tamaño de la red. Además de los tres formatos básicos, existe uno para multicasting, usado para envío de mensajes a un grupo de hosts, y otro reservado para uso futuro.

La estnxtura de los diferentes formatos es la que sigue:

Clase A rEdentificador de red bdentificador de host 1 1 17 bits (128 redes) ~ 124 bits (16.7~-&llones) 1 Clase B [“6-bdentificador de red bdentificador de host 1 1 { (14 bits (16.3 niles) 116 bits (65.5 miles) I

12

Clase C ~ i " ~ ~ ~ 1 d e n t i f i c a d o r de red IIdentificador de host i-r-rmts (2.09 millones) 18 bits (256 hosts) Clase D 1 F f i i b i r e c c i ó n multicast Frci p 8 bits (268.4 millones) Clase E 1 11 11 11 10 bspacio reservado para usos futuros t-[ITn p 7 bits (134.2 m i l l o n e s )

Vemos que los primeros bits identifican la clase de dirección IP, que va seguido de un prefijo de identificación de red, y seguido de un identificador de host.

La clase A se usa para grandes redes que tengan más de 216 (65,536) hosts, contiene 7 bits para direcciones de red, con lo que permite tener hasta 128 redes, con 16.777.216 ordenadores cada una. Las direcciones están comprendidas entre 0.0.0.0 y 127.255.255.255, y la máscara de subred será 255.0.0.0.

La clase B se usa para redes de tamaño intermedio, entre 28 (256) y 216 hosts, contiene 14 bits para direcciones de red y 16 bits para direcciones de hosts. El número máximo de redes es 16.536 redes, con 65.536 ordenadores por red. Las direcciones están comprendidas entre 128.0.0.0. y 191.255.255.255, y la máscara de subred será 255.255.0.0.

La clase C corresponde a redes con menos de 256 hosts, contiene 21 bits para direcciones de red y 8 para hosts, lo que permite tener un total de 2.097.142 redes, cada una de ellas con 256 ordenadores. Las direcciones están comprendidas entre 192.0.0.0. y 223.255.255.255, y la mascara de subred será 255.255.255.0.

El cuarto tipo, la clase D, se dedica a tareas de multicasting, se usa para transmitir un mismo mensaje a un grupo de hosts determinado. La clase D se reserva todas las direcciones para multidestino (multicast), es decir, un ordenador transmite un mensaje a un grupo especifico de ordenadores de esta clase. Las direcciones están comprendidas entre 224.0.0.0. y 239.255.255.255.

Finalmente, la clase E se utiliza exclusivamente para fines experimentales. Las direcciones están comprendidas entre 240.0.0.0. y 247.255.255.255.

Para asegurar que la parte de identificación de red de una dirección Internet es única, todas las direcciones son asignadas por una autoridad central, el Centro de Información de Red. (NIC: Network Information Center)

Esta autoridad central tan sólo asigna el prefijo de red de la dirección y delega la responsabilidad de asignar las Qrecciones de host individuales a la organización solicitante. A las redes de área local con pocas computadoras (menos de 255) se le asignan direcciones de la clase C, pues se espera que surjan un gran número de ellas. A redes muy grandes, como ARPANET, se les asigna la clase A, ya que se espera que no surjan demasiadas.

A la hora de trabajar con direcciones IP, usamos la notación decimal. La dirección expresada de esta forma vendrá dada por cuatro enteros positivos separados por puntos, donde cada entero se corresponde con el valor de un byte de la dirección IP.

I

IPv6 : Internet Protocol Ver. 6

IPv6' es la nueva versión del protocolo IP, (actualmente se maneja extensivamente IPvl), aunque también es conocida como IPng (Internet Protocol Next Generation). IPv6 es la versión 6 de IP, debido a que la numero 5 no paso de la fase experimental. La compatibilidad con la versión 4 es solo al nivel de formato ya que solo se le agregaron algunos campos y se extendieron otros, algunas de las modificaciones, están encaminadas a mejorar la seguridad en la red, que apenas existía en la versión 4. Pero existe un importante y severo problema de compatibilidad en la implementación. Para usar el nuevo protocolo, los administradores de red deberán cambiar el software de protocolos en ,todos! los dispositivos conectados y como los protocolos forman parte del kernel de los sistemas operativos de muchas máquinas conectadas, cambiar los protocolos IP Significaría cambiar también el sistema operativo además, habría que realizar también cambios a varios niveles: routers, hosts, y servidores de DNS; en algunas ocasiones hasta el hardware habría que cambiar debido a un modo de implementarlos de una manera más rápida.

Formato de la cabecera

Esta cabecera ocupa el doble que la anterior, pero se ha simplificado omitiendo algunos campos y haciendo que otros sean opcionales. De esta manera, los routers no tienen que procesar tanta información.

Longitud ISiguiente cabecera piempo de vida /Dirección de Origen (128 bits) /Dirección de Destino (128 bits)

Figura 6. Formato de la Cabecera del IPv6

La descripción de los campos es la siguiente:

O O U

O U

U O U

Versidn: Este campo ocupa 4 bits, y contiene el numero de versión del IP, en este caso 6. Prioridad: Ocupa 4 bits, y indica la importancia del paquete que se esta enviando. Etiqueta de Flujo: Ocupa 24 bits. Indica que el paquete requiere un tratamiento especial por parte de los routers que lo soporten. Longitud: Ocupa 16 bits. Indica la longitud en bytes de los datos del mensaje Sigzliente Cabecera: Ocupa 8 bits e indica a que protocolo corresponde la cabecera que esta a continuación de la actual. Tiempo de vida: Ocupa 8 bits y tiene la misma función que éI la versión 4. Dirección de origen: Ocupa 128 bits (16 octetos), y es el número de dirección del origen. Dirección de Destino: Ocupa 128 bits (16 octetos). Es el número de dirección del destino.

El cambio más significativo en las drecciones ha sido, que ahora, se refieren a un interfaz y no a un nodo, aunque como cada interfaz pertenece a un nodo, es posible referirse a estos mediante su interfaz.

El número de direcciones diferentes se ha multiplicado de una manera exagerada. Teóricamente, es posible tener 2128 drecciones diferentes. Este numero quiere decir que se podrían llegar a tener mas de 665.000 trillones de direcciones por metro cuadrado, aunque si siguieran una jerarquía, este número decrece hasta 1564 direcciones por metro cuadrado en el peor caso o tres trillones siendo optimistas.

I

14

Direccionamiento IPv6

En el IPv6 existen tres tipos básicos de direcciones:

o Direcciones unicast: Están dirigidas a una única interfaz en la red. Actualmente se dividen en varios grupos, y existe un grupo especial que facilita la compatibilidad con las direcciones de la versión 4.

o Direcciones anycast: Identifican a un conjunto de interfaces de red. El paquete se enviará cualquier interfaz que forme parte del conjunto. En realidad son direcciones unicast que se encuentran asignadas a varias interfaces.

o Direcciones multicast: Identifican a un conjunto de interfaces de la red, de manera que cada paquete es enviado a cada uno de ellos individualmente.

Existen 3 formas para representar direcciones IPv6 mediante cadenas de texto:

1.- La forma más indicada es mediante la estructura X:X:X:X:X:X:X:X, donde los valores X son los valores en hexadecimal de cada bloque de 16 bits de la dirección.

Ejemplos:

1080:0:0:0:8:800:200C:417A

2.- El segundo método permite agrupar largas series de O's, para hacer más legibles las direcciones, el uso de "::" indica múltiples grupos de 16 bits a O.

Ejemplos:

1080:0:0:0:8:800:200C:417A podría representarse como

1080::8:800:200C:417A

FFO1:0:0:0:0:0:0:43 podría representarse como FFO1::43

Sólo puede usarse "::" una vez en una dirección

3.- El tercer método resulta el más indicado para representar lrecciones IPv6 que contengan direcciones 1Pv4, los 2 últimos bloques de 16 bits se representan como 4 bloques de 8 bits mostrando sus valores en decimal, como en IPv4.

Ejemplos:

0:O:O:O:O:O: 13.1.68.3 ó :: 13.1.68.3

0:0:0:0:0:FFFF:129.144.52.38 ó ::FFFF:129.144.52.38

Los diferentes tipos de direcciones son especificados por los bits de mayor peso de la dirección, cada tipo tiene asignado u11 prefijo, de longitud variable para cada tipo.

UDP: User Datagram Protocol

El protocolo de uso de datagramas UDP proporciona aplicaciones con un tipo de servicio de datagramas orientado a transacciones. El senicio es muy parecido al protocolo IP en el sentido de quemo es fiable y no esta orientado a la conexión. El UDP es simple, eficiente e ideal para aplicaciones como el envio de voz en donde es más importante la entrega rápida que corregir errores de transmisión. El receptor tendrá que compensar la perdida de datos y ordenar los que así lo requieran.

Una dirección IP sirve para dirigir el datagrama hacia una máquina en particular, y el número de puerto de destino en la cabecera UDP se utiliza para dirigir el datagrama UDP a un proceso específico localizado en la cabecera 1P. La cabecera UDP también contiene un número de puerto origen que permite al proceso recibido conocer como responder al datagrama.

El datagrama UDP contiene cuatro campos, que son Número del Puerto de Origen, Número del Puerto de Destino, Longitud del mensaje y Checksum.

Iloctet +o loctet +I loctet +2 loctet +3 1 I$-O (Source port pestination port FZ-bessage'Leigth' r I U D P Data

v r r Figura 7. Formato del UDP

0 Nheros de Puerto de Origen y Destino

Estos números, junto con las direcciones IP definen el punto final de la comunicación. El número del puerto de origen, puede tener valor cero si no se usa. El número del puerto de destino solo tiene sentido en el contexto de un datagrama UDP y una dirección IP en particular. El número de puerto de origen es un campo de 16 bits. El puerto de destino tiene la misma longitud.

Longitud del Mensaje

Este campo tiene una longitud de 16 bits y contiene el número total de octetos que forman el datagrama, incluida la cabecera.

0 Checkszm

El uso del checksum es opcional, y este campo debe ponerse a cero si no es utilizado. Mientras que el checksum del datagrama IP solo tiene en cuenta la cabecera del mensaje, el UDP tiene su propio checksum para garantizar la integridad de los datos. La longitud de este campo es de 16 bits, y esta formado por la suma de los campos del UDP, y algunos campos del IP.

16

RTP: Real Time Protocol

El protocolo de Tiempo Real (RTP) definido por la IETF (Internet Engineering TaskForce) RFC 1889, maneja los aspectos relativos a la temporización, marcando los paquetes UDP con la información necesaria para la correcta entrega de los mismos.

QoS (se lee quius) se definió por la ITU“13 en la recomendación 1.350 como: “Calidad de Servicio” o “Efecto colectivo de rendimiento que determina el grado de satisfacción del usuario de ese servicio especifico”, ya que anteriormente las redes IP no ofrecían ningún tipo de QoS se presentaba un severo problema para las aplicaciones de transmisión de medios de información masivos (voz e imagen).

Por su parte en el IETF‘ de Sun Microsystems, desarrollaron varios tipos de protocolos destinados a ofrecer QoS, de forma que estos protocolos puedan perfilar las limitaciones impuestas por redes basadas en protocolo IP.

Mientras RTP se diseña para satisfacer las necesidades principalmente de participantes de multiconferencia, no se limita a esa aplicación particular. El almacenamiento de datos continuos, interactivo, y simulación distribuida, también pueden encontrar en RTP un protocolo aplicable.

Sin embargo, el Internet actual no puede apoyarse todavía de lleno en la demanda potencial para los servicios de tiempo-real. El uso de gran ancho de banda en los servicios RTP, como video, puede degradar potencialmente la calidad de servicio de otros servicios de la red. Así,’ los impulsores de nuevas tecnologías deben tomar precauciones apropiadas para limitar el accidental uso de ancho de banda. La documentación de la aplicación debe perfilar claramente las limitaciones y el posible impacto operacional de gran ancho de banda real.

El Internet, como otras redes de conmutación de paquetes, pierde de vez en cuando paquetes de los nuevos pedidos y los retrasa en cantidades inconstantes de tiempo. Para cubrir estos deterioros, RTP contiene información cronometrada y un número de la sucesión que les permite a los receptores reconstruir el cronómetro producido por la fuente. Esta reconstrucción cronometrada se ha realizado separadamente para cada fuente de paquetes RTP en la conferencia. El número de la sucesión también puede usarse por el receptor para estimar cuántos paquetes están perdidos. La sucesión de números incluidos en RTP le permiten al receptor reconstruir la sucesión del paquete de remitente, pero los números de la sucesión también podrían usarse para que se determine la situación apropiada de un paquete, por ejemplo en video, descifiando, sin necesariamente descifrar paquetes en sucesión.

RTP puede ser usado para servicios de red unicast y multicast. Sobre una servicio unicast, se separan copias de los datos enviados desde la fuente a cada destino, mientras que en la multicast, los datos son enviados desde una sola’fuente y la red es responsable de transmitir los datos a múltiples locaciones. El servicio de red multicast soportado por IP, es más eficiente para muchas aplicaciones multimedia, como video y audio conferencias.

De esta manera, en la balanza comparativa acerca de que es mejor, perder datos mediante UDP o tener fuertes retrasos mediante TCP de banda angosta, podemos decir que.. .

. .. “Es más fácil compensar la perdida de datos, que compensar largos retrasos al recibirlos”

Hablando de datos como audio y video este enfoque es el más adecuado, ya que el cerebro humano puede reconstruir perdidas considerables de infornlación.

3 United Nations International Teleconmunications Union Internet Enginner Task Force

La cabecera RTP tiene el siguiente formato (Figura 8):

Sequence Number

synchronization source (SSRC) identifier contributing source (CSRC) identifiers

Figura 8. Fornlato RTP

Los primeros doce octetos están presentes en cada paquete de RTP, mientras la lista de identificadores de CSRC sólo está presente cuando es insertado por un mezclador.

Los campos tienen el significado siguiente:

F'ersicin p): 2 bit Este campo identifica la versión de RTP. La versión definida por esta especificación es dos (2). (El valor 1 es usado por el primer bosquejo de la versión de RTP y el valor O es usado por el protocolo inicialmente llevado a cabo como una herramienta en la transmisión de audio.)

Padding (P): 1 bit Si el bit de padding es fijo, el paquete contiene uno o más octetos de padding adicionales al final. El último octeto de padding o relleno contiene una cuenta de cómo deben ignorarse muchos octetos del relleno. El padding puede necesitarse por algunos algoritmos de encriptación con tamaños de bloque fijos o para varios paquetes de RTP llevándolos en una capa baja la unidad de datos protocolares.

Extensicin (x): 1 bit Si el bit de la extensión es fijo, el título fijo se sigue por exactamente una extensión del título.

CSRC count (C.C.P.): 4 bit La cuenta de CSRC contiene el número de identificadores de CSRC que sigue el título fijo.

Marker (M): 1 bit La interpretación del marcador es definida por un perfil. Permite eventos significativos como límites del marco al cual se ha marcado en la trama.

Las aplicaciones de RTP se dividen a menudo en dos partes:

1) La necesidad de poder recibir datos de la red (Clientes de RTP) y 2) La de poder transmitir datos por la red (Servidores de RTP).

Algunas aplicaciones tienen ambas funciones, por ejemplo, las aplicaciones de conferencia múltiple capturan y transmite datos de la red, al mismo tiempo que están recibiendo.

Existen varios tipos de aplicaciones, por ejemplo:

I ) Las aplicaciones de Conferencia múltiple necesitan poder recibir paquetes de datos desde una sesión de RTP y entregarlo a la consola.

18

2) Una aplicación de máquina contestadora telefónica, pro ejemplo, necesita poder recibir un paquetes de datos desde una sesión de RTP y guardarlo en un archivo.

3) O bien, una aplicación que graba una conversación o la conferencia de un grupo debe poder recibir un paquete de datos desde una sesión de RTP y entregarlos a la consola y guardarlo en un archivo.

Las aplicaciones Servidor RTP transmiten tramas capturadas, guardadas o recibidas desde la red, por ejemplo:

En una aplicación de conferencia de grupo, una trama podría capturarse desde una video cámara y podría enviarse a una o más sesiones RTP. Las tramas podrían ponerse en código en formatos de distintos tipos de medios (audio y video) y podrían mandarse en varias sesiones de RTP para la conferencia con receptores heterogéneos, es decir, algunos podrían solo requerir el audio debido a limitaciones de ancho de banda en su red.

RTCP: Real Time Control Protocol

Este protocolo de control en tiempo real desarrollado también por la IETF, se utiliza principalmente para detectar situaciones de congestión de la red y tomar, en su caso, acciones correctoras.

El protocolo de control RTP (RTCP) esta basado en la transmisión periódica de paquetes a todos los participantes en una sesión, usando el mismo mecanismo de la distribución que en los paquetes de datos. El protocolo subyacente debe proporcionar el multiplexado de los datos y paquetes de mando, usando números del puerto separados por ejemplo con UDP.

RTCP realiza cuatro funciones:

1. La función primaria es proporcionar regeneración en la calidad de la distribución de los datos. Ésta es una parte integra del papel de RTP como un protocolo de transporte y se relaciona al flujo y funciones de mando de congestión de otro protocolo de transporte. La regeneración puede ser directamente útil para el control de codificaciones adaptables, pero los experimentos con multicasting de IP han mostrado que también es crítico recibir regeneración de los receptores cuando existe un diagnóstico de "faltas en la distribución". Enviando regeneración de la recepción se informa a todos los participantes que un problema se presentó, así se evaluará si esos problemas son locales o globales. Con un mecanismo de distribución como el multicast de IP, también es posible para una entidad como un proveedor de servicio de red quien esta involucrado en la sesión, el recibir la información de la regeneración y actuar como un amonestador para diagnosticar problemas de la red.

2. RTCP llevan un identificador nivel-transporte, una fuente de RTP referida con el canónico CNAME. Desde que los identificadores de SSRC pueden cambiar si un conflicto se descubre o un programa es reiniciado, los receptores le exigen al CNAME que guarde huella de cada participante. Los receptores también requieren el CNAME para asociar datos múltiples de un participante dado en un juego de sesiones de RTP relacionadas, por ejemplo para sincronizar audio y video.

3 . Las primeras dos funciones requieren que todos los participantes envían paquetes de RTCP, por consiguiente la proporción debe ser controlada para que RTP acepte un número grande de participantes. Teniendo en cuenta que cada participante envía sus paquetes de control a todos los otros, cada uno puede observar el número de participantes independientemente. Este número se calcula en proporción a los paquetes que se envían.

4. EL cuarto, la h c i ó n optativa es llevar información de control de sesión mínima, por ejemplo el participante, identifica que debe ser desplegado una aplicación en la interfaz del usuario, este probablemente utilizará "control de flujo" donde los participantes entran y salen sin control del número de miembros o negociación del parámetro. RTCP localiza a todos los participantes, pero necesariamente no se espera que apoye a todos los requisitos de comunicación de mando de una aplicación. Un protocolo de control de sesión de alto-nivel está más allá del alcance de este documento.

Funciones 1-3 son obligatorias cuando RTP se usa en el ambiente IP multicast, y se recomienda para todos los ambientes. Se aconsejan a los diseñadores de aplicaciones RTP que eviten mecanismos que sólo pueden trabajar en modo del unicast.

Aplicaciones de RTP y RTCP

VoIP: Voice on IP

Voz sobre IP (VoIP) es una tecnología que permite digitalizar y codificar la voz en paquetes de datos IP para su transmisión en una red conmutada de paquetes que utilice el conjunto de protocolos TCPDP. Debido al volumen de datos generado por una aplicación como VoIP, esta tecnología se encuentra en hcionamiento en redes corporativas privadas, sin embargo se establecen hoy en día las bases para el uso de esta aplicación para Internet, ya que la calidad de la voz depende del tráfico de datos que exista en el momento de la conversación.

A fmales de 1997 el VoIP Forum ha llegado a un acuerdo que permite la interoperabilidad de los distintos elementos que pueden integrarse en una red VoIP. Debido a la ya existencia del estándar H.323 del ITU-T, que cubría la mayor parte de las necesidades para la integración de la voz, se decidió que el H.323 hera la base del VoIP. De este modo, el VoIP debe considerarse como una clarificación del H.323, de tal forma que en caso de conflicto, y a fin de evitar divergencias entre los estándares, se decihó que H.323 tendría prioridad sobre el VoIP. El conjunto de protocolos utilizados en VolP se muestran en la Figura 9. El VoIP tiene como principal objetivo asegurar la interoperabilidad entre equipos de diferentes fabricantes, fijando aspectos tales como la supresión de silencios, codificación de la voz y direccionamiento, y estableciendo nuevos elementos para permitir la conectividad con la infraestructura telefónica tradicional (ver figura 10). Estos elementos se refieren básicamente a los servicios de directorio y a la transmisión de señalización por tonos multifrecuencia (DTMF).

I Establecimiento de llamada y Control I I Presentacihn

Uireccionamiento

RAS(H.225) I DNS DNS + RTFfRTCP I H.245 IQ.931 ki.225)

Compresi in de audio (3.71 1 á Direcciona- DTFV,F G.723 miento

I Transporte LlDP Transporte TCF

Enlace Físico

Figura 9. Protocolos utilizados en VoIP

20

I

Figura 10. Red VoIP

El VoIPkI.323 comprende una sene de estándares y se apoya en un conjunto de protocolos que cubren los distintos aspectos de la comunicación:

Direccionamiento:

1 .RAS (Registration, Admision and Status). Protocolo de comunicaciones que permite a una estación H.323 localizar otra estación H.323 a través del Gatekeeper. 2.DNS (Domain Name Service). Servicio de resolución de nombres en direcciones IP con el mismo fin que el protocolo RAS pero a través de un Servidor DNS

Señalizacicin:

1.Q.931 Señalización inicial de llamada 2.H.225 Control de llamada: señalización, registro y admisión, y paquetización / sincronización del stream (flujo) de voz. 3.H.245 Protocolo de control para especificar mensajes de apertura y cierre de canales para streams de voz

Compresión de voz:

1 .Requeridos: G.711 y G.723 2.Opcionales: G.728, G.729 y G.722

Trnnsmisidn de voz:

1.UDP. La transmisión se realiza sobre paquetes UDP, pues aunque UDP no ofrece integridad en los datos, el aprovechamiento del ancho de banda es mayor que con TCP. 2.RTP (Real Time Protocol). Maneja los aspectos relativos a la temporización, marcando los paquetes UDP con la información necesaria para la correcta entrega de los mismos en recepción,

Control de la transmisicin

1.RTCP (Real Time Control Protocol). Se utiliza principalmente para detectar situaciones de congestión de la red y tomar, en su caso, acciones correctoras.

El hecho de que VoIP se apoye en un protocolo de nivel 3, como es IP, nos permite una flexibilidad en las configuraciones que en muchos casos está todavía por descubrir. Una idea que parece inmediata es que el papel tradicional de la central privada telefónica quedaría distribuido entre los distintos elementos de una red VoIP. Será el paso del tiempo y la imaginación de las personas involucradas en estos entomos, los que irán definiendo aplicaciones y servicios basados en VoIP.

Actualmente podemos partir de una serie de elementos ya disponibles en el mercado y que, según diferentes diseños, nos permitirán construir las aplicaciones VoIP.

Estos elementos son:

0 Teléfonos IP. Adaptadores para PC.

0 Hubs Telefónicos. 0 Gateways (RTC / IP).

Gatekeeper. 0 Unidades de audioconferencia múltiple. (MCU Voz) 0 Servicios de Directorio.

22

Tecnología de objetos

Una de las preocupaciones actuales más urgentes de la industria de la computación es la de crear software y sistemas operativos lo más rápido posible y a menores costos. Para hacer un buen uso del poder cada vez mayor de las computadoras, se necesita un software de mayor complejidad. Aparte de más complejo, también es necesario que dicho software sea más confiable. La alta calidad es esencial en el desarrollo del software, ya que una calidad pobre es un desperdicio de dinero y tiempo.

Las técnicas orientadas a objetos permiten que el software se construya a partir de objetos de comportamiento específico. Los propios objetos se pueden construir a partir de otros, que a su vez pueden estar transformados por otros objetos. Esto nos recuerda una maquinaria compleja, construida por partes, subpartes, sub-subpartes, etc.

Otro de los enfoques para la construcción de los sistemas parte de la hipótesis de que deberían estar compuestos por elementos perfectamente definidos, objetos encerrados, definidos y materializados haciendo de ellos agentes independientes. La adopción de los objetos como medios para la construcción de sistemas informáticos ha colaborado a la posibilidad de intercambiar los diferentes elementos.

LDefiniciones?

Objeto: Un objeto es cualquier cosa , real o abstracta. Este es creado como una instancia de un tipo de objeto. Cada objeto tiene una identidad Única que los distingue e independiente de cualquiera de sus características. Cada objeto ofrece una o más operaciones.

Como se explicó un objeto es cualquier cosa, pues bien, si es cualquier cosa imaginemos un televisor. En este caso es algo real, pero nos pudimos haber imaginado algo abstracto (Ej. Un número complejo). Si tenemos dos televisores exactamente idénticos, estos serán dos objetos (no necesitamos distinguirlos con un código o una marca, no, solo son dos objetos diferentes). Cada uno en distintos lugares del espacio y no importa lo que le suceda al otro seguirán siendo dos objetos independientes. Es todo lo que necesitamos saber para comprender que un televisor es un objeto.

Internamente el televisor tiene algunos circuitos básicos de funcionamiento, un receptor, un amplificador, un filtro, etc. posiblemente no sabemos como están construidos estos circuitos, desde el punto de vista de objetos, esto está encapsulado. Solo sabemos de la existencia de estos porque al encender el televisor, este da una imagen (si ésta funciona claro), podemos sintonizar programas, etc. Esta es la forma de enviar un mensaje a los circuitos para que estos se ajusten y dejen pasar ímicamente la señal del programa deseado. La comunicación con los objetos se hace a través de mensajes. El modelo del televisor (con sus circuitos) puede ser utilizado para diseñar un nuevo aparato de recepción, el principio de hncionamiento de los televisores es ímico, de manera que puede haber una reutilización de su tecnología para crear nuevos aparatos. Por último un televisor puede ser usado como monitor de una computadora, proyector de cine de un VHS, etc. en término de objetos esto se conoce como polimorfismo. Pero algún experto leyendo esto dirá que un televisor como objeto no es polimórfko, el concepto de polimorfismo más formalmente se aplica únicamente a las operaciones sobre objetos.

Definiciones básicas:

Ahstmcción: Define la relación entre un grupo de objetos tales que, un tipo de objeto representa un conjunto de características las cuales son compartidas por otros tipos de objetos.

Encapszhmiento: Define el empaquetamiento de operaciones y datos dentro del objeto, tal que los datos son únicamente accesibles a través de su interfaz.

I<eznahi/idad: Define la habilidad de rehusar objetos y clases de objetos con la implementación de un sistema.

Especialización: Ocurre cuando un tipo de objeto hereda operaciones, tipos de atributos y tipos de relaciones de uno o más supertipos (con posibles restricciones).

Comzrnicnción entre Objetos: En sistemas orientados a objetos, toma la forma de un envío de requerimientos por parte de un objeto a otros objetos.

Polimor-ismo: Ocurre cuando una operación puede ser aplicada a varios tipos.

Las ventajas que aporta la orientación a objetos en general ha dado lugar a que este paradlgma se intente aplicar a otros ya existentes. Algunos de los problemas que afectan actualmente a los lenguajes orientados a objetos están relacionados con dos aspectos: complejidad del modelo de programación e ineficiencia de la implementación. El primer problema se produce porque la combinación de todas las características de los dos paradigmas (el estructurado y el orientado a objetos) da lugar a modelos de programación que son muy complejos de utilizar. El segundo problema tiene su origen en el hecho de que los objetos se comunican mediante paso de mensajes, lo que da lugar a que el coste de la invocación de operaciones sea elevado, tanto en el caso de objetos locales como remotos.

El trabajo que se esta llevando a cabo hoy en día, se centra en el estudio de técnicas de inlplementación de esté tipo de lenguajes sobre sistemas distribuidos. De este modo, se trata de permitir la replicación y migración de objetos con el fin de reducir el coste de las invocaciones remotas. Asimismo, se trata de simplificar el modelo de objeto con el fin de no aumentar la complejidad de modelo de programación resultante en lo posible. El objetivo de estos trabajos de investigación ha sido diseñar un sistema de ejecución (runtime system) basado en lenguajes de medio y alto nivel como C++ que fuese portable y eficiente.

La disponibilidad de sistemas multiprocesadores añadió nuevas perspectivas a esta línea de investigación, ya que aprovechar el potencial de estas máquinas constituía un reto que había que afrontar. De este modo, el objetivo de la portabilidad no se reduce únicamente a computadoras que ejecutan distintos sistemas operativos, sino también a sistemas que presentan una arquitectura diferente. La solución que se ha adoptado es utilizar hebras (multithreading) en la implementación.

Como resultado de las investigaciones realizadas, se han construido sistemas de ejecución que fimcionan sobre distintas versiones del sistema operativo UNIX (actualmente, Solaris 2.X, Digital UNIX 4.0 e IRIX 6.4) y sobre Windows NT 4.0. , además de redes de estaciones de trabajo y en sistemas multiprocesador como Digital Alpha Server 4100 y SGI Origin-2000.

24

Java

Java es un lenguaje de programación orientado a objetos que ha sido diseñado para crear ambientes distribuidos y heterogéneos en el Internet, aunque puede ser usado para elaborar aplicaciones que no necesariamente interactúen con el Internet. Un programa escrito en Java puede ejecutarse por medio de un ambiente de navegación en el WWW (un browser como Netscape) que soporte Java. Java es entonces un lenguaje de programación, y tiene las siguientes características:

a) Simple. Es similar a C++, y no se requiere de mucha capacitación para poder programar, por lo que uno puede producir programas en Java relativamente poco tiempo después de comenzar a trabajar en el lenguaje.

b) Distribuido. Conjunta la filosofia Cliente/Servidor con el paso de mensajes entre objetos.

c) Interpretado. El intérprete Java ejecuta un &digo denominado "Java bytecode".

d) Robusto. Tiene un modelo de manejo de memoria que evita los apuntadores de Ctt.

e) Seguro. Las aplicaciones desarrolladas en Java y ejecutadas vía Internet no pueden ser modificadas sin autorización.

f ) Independiente de arquitectura. El compilador Java genera "Java bytecode" el cual es un formato independiente a cualquier arquitectura, diseñado para transportar código entre diferentes plataformas de hardware y software.

g) Portirtil. Puede ejecutarse en diferentes plataformas, gracias a la especificación de una máquina abstracta: la "Java Virtual Machine".

h) Alto desenpeño. Java tiene un colector de basura automático que nos permite más fácilmente disponer de memoria cuando es requerida. Puede tenerse una interfaz entre código ya elaborado en la máquina correspondiente y la aplicación escrita en Java. Esto es importante especialmente en lo referente a gráficos y animación.

i) Mtdtithread. Permite varias actividades ejecutarse concurrentemente.

j) Dinirrnico. Las aplicaciones son adaptables a cambios en el ambiente, pudiéndose cargar nuevos módulos desde cualquier sitio de la red. Asimismo, esos nuevos módulos pueden ligarse en tiempo de ejecución. (run time execution)

k) Orientndo a objetos.

Java al ser orientado a objetos permite:

Encopsuldo: La base para el encapsulado de Java es el concepto de clase. Una clase representa una abstracción de un conjunto de objetos que tienen el mismo comportamiento y la misma estructura. Un objeto es entonces una instancia de una clase dada. Las estructuras de datos de una clase se definen en base a un conjunto de variables las cuales se denominan "variables de la instancia". Finalmente, un método es la representación de las acciones del objeto. Un método es, en términos de programación orientada a objetos, un mensaje. Así pues, las estructuras y los métodos de una clase pueden ser privados o pilblicos. De esta manera los métodos de otros objetos no pueden cambiar las variables de objetos cuyas estructuras son privadas.

Po/in?orfi.smo: El polimorfismo permite milltiples implementaciones de métodos, dependiendo del tipo de objeto que se indica al invocar el método correspondiente. De esta manera el polimorfísmo permite que el mismo mensaje enviado a cfiferentes objetos resulte en acciones dependientes del objeto que recibe el mensaje.

Herencia: Un objeto de una clase hereda los métodos y estructuras de su super-clase. La herencia facilita la reutilización de código.

Alcance dinrimico: Es posible enviar mensajes a objetos sin conocer su tipo específico, aún a través de la red. Esto permite una gran flexibilidad en tiempo de ejecución.

Principales librerías de Java.

jmalnng :Colección de tipos básicos siempre importados a cualquier unidad de compilación. Aquí están las declaraciones de objetos, clases, threads, excepciones, wrappers de los tipos de datos primitivos y otras clases bdamentales.

jma.io : Archivos de flujo (stream) y acceso aleatorio. Librería estándar de entrada y salida.

jnvrr.net : Librería que apoya interfaces con Telnet y URLs

java.util : Clases como diccionarios, tabla de hash, stack, técnicas de codificación y decodifícación, hora, fecha, etcétera.

java.mYt : Abstract Windowing Toolkit que proporciona una capa abstracta que permite llevar una aplicación en Java de un sistema de ventanas a otro. Contiene clases para componentes básicos de la interfaz, tales como eventos, colores, tipos de letra, botones, campos de texto, etcétera.

Manejo de memoria y Recolección de basura.

Java tiene un colector automático de basura. El manejo de memoria en Java esta basado en objetos y referencias a objetos. No hay apuntadores en Java (a diferencia de C). El manejador de memoria de Java lleva un registro de las referencias a un objeto. Cuando un objeto no tiene referencias entonces se convierte en un candidato para ser considerado basura. Por ejemplo, veamos la siguiente clase:

I

26

11 Voltea una cadena de caracteresllllllllllllllllllllllllllllllll class CADENA-ALREVES f

public static String volteala(String FUENTE) f

int I, String LONGITUD = FUENTE.length0; StringBuffer DESTINO = new StringBuffer(L0NGITUD); for ( I = (LONGITUD - 1); I >= O; I--) f

. I

1

DESTINO.appendChar(FUENTE.charAt(I));

return DESTINO.toString0;

1

En este ejemplo la variable DESTINO es usada como un objeto temporal de referencia durante la ejecución del proceso de invertir una cadena. Cuando el método "volteala" llega a su return la referencia al objeto DESTINO ya no existe, siendo entonces DESTINO un candidato a ser basura. Los elementos de clase String (como FUENTE) tienen los métodos length y charAt (el cual regresa el carácter correspondiente a la posicion indicada). Los elementos de la clase StringBuffer tienen los métodos appendchar (el cual incluye un caracter al final del buffer) y tostring (el cual transforma los datos del buffer en una representación de tipo String).

Lo que no tiene Java.

A diferencia de C y C++, en Java :

a) No hay Mefine b) No hay definición de clases como estructuras. c) No hay herencia múltiple. d) No hay goto. e) i No hay apuntadores! f) No hay funciones (finctions). Java permite una programación orientada a objetos sin estilo funcional o estructural. Lo que hace una función en C++ se hace en Java al definir una clase y creando los métodos para dicha clase.

Applets

Un applet es una pequeña aplicación accesible en un Servidor Internet, que se transporta por la red, se instala automáticamente y se ejecuta in situ como parte de un documento web (definición de Patrick Naughton). Dado que Java es multiplataforma y los applets son soportados por ambos navegadores, su uso se ha popularizado bastante. Los applets tienen, sin embargo, un problema que impide que se utilicen más habitualmente. Este problema consiste en que, al igual que sucede con las imágenes, cuando colocamos un applet en una .página web debemos definir un rectángulo de un tamaño determinado donde permanecerá el mismo, no pudiendo actuar fuera de sus márgenes.

AppletViewer

Podemos utilizar un navegador web como Explorer, Netscape o HotJava para ver nuestros applets, especialmente cuando los queremos incluir dentro de una página web ya construida. Sin embargo, mientras programemos el applet, será recomendable utilizar el programa que viene incluido en el JDK (Java Developer Kit) para probarlos. El appletviewer (nombre francamente explicativo) recibe como parámetro una página HTML y nos muestra el applet incluido en la misma en acción. Para utilizarlo, por lo tanto, debemos saber como incluir applets en una página HTML.

Ejemplo de código que ejecuta un Applet:

AdiosMundo.htm1

<HTML> <BODY> <APPLET CODE="AdiosMundo.class" WDTH="200" HEIGHT="70"> </APPLET> </BODY> </HTML>

Aparte de las etiquetas que marcan el comienzo y el fin del documento HTML y del cuerpo del mismo vemos la etiqueta APPLET, que es la encargada de llamar a estas pequeñas aplicaciones. Vemos que el parámetro CODE define la clase resultante de compilar el applet y que los parámetros WIDTH y HEIGHT definen el tamaño del rectángulo donde se va a meter el mismo. Si guardamos el archivo anterior como AdiosMundo.htm1, para ver el applet deberíamos ejecutar: appletviewer AdiosMundo.htm1

Nuestro Primer Applet.

Vamos a crear nuestro primer applet, casi equivalente al típico "Hola mundo" de toda la vida:

/*** * Archivo fuente: AdiosMundo.java * Applet AdiosMundo * CAPPLET CODE="AdiosMundo.class" WIDTH="200" HEIGHT="70"></APPLET> *I

import java.applet.Applet; import java.awt.*;

public class AdiosMundo extends Applet {

public void paint(Graphics g) {

1 g.drawString("Adios, mundo",20,20);

Lo grabamos como AdiosMundo.java y ejecutamos el appletviewer con el siguiente comando: applemiewer AdiosMundo

28

Esto parece contradecirse con lo explicado anteriormente. ¿No teníamos que llamar a una página HTML que tuviera la etiqueta APPLET correspondiente? Bueno, sí. Lo que sucede es que appletviewvr ignora cualquier cosa que no sea una etiqueta APPLET, de modo que podemos incluirla en un comentario en nuestro código fuente y así nos ahorramos tener que escribir una página HTML por cada ejemplo que veamos. Vamos ahora a examinar el código paso a paso:

import java.applet.Appllet; import,javcl.aw~t. *:

En todos nuestro applets deberemos, como mínimo, incluir estas dos sentencias de importación. En la primera importamos la clase Applet, de la cual derivaremos nuestros applets. La segunda permite importar las clases de la librería AWT, que nos permitirán dibujar en el rectángulo asignado al applet.

public class AdiosMundo extends Applet { J

1

Nuestros applet siempre van a ser clases derivadas de Applet, pues en esta clase y en sus clases padre se definen los métodos que deberemos sobreescribir para que nuestros applets respondan a los eventos generados desde el navegador.

Public voidpaint(Graphics g) { t

Este es el método que debemos sobreescribir para dlbujar en el rectángulo asignado a nuestro applet. Recibe un parámetro que es una referencia a una instancia de tipo Graphics. Esta clase permite definir lo que se suele denominar lienzo (o Canvas). El lienzo es precisamente ese rectángulo del que hemos estado hablando hasta ahora.

g.drmYString("Adios mundo, bienvenido. .. el Universo". 20,20);

La clase Graphics dispone de muchos métodos para dibujar en el lienzo. Éste, concretamente, nos permite dibujar un texto en la posición que queramos. En este caso el texto se pintará 20 pixels a la derecha del borde izquierdo de la pantalla y otros 20 más abajo del borde de arriba.

Versiones actualizadas del JDK pueden bajarse del Web Site de Sun Micrsystem para la realización de todos lo ejercicios (http://www.sun.com).

Ciclo de vida de un applet

Como hemos visto, un applet se ejecuta en una página web y ese entorno en el que está va a determinar el ciclo de vida del mismo. La clase Applet dispone de varios métodos sin código dentro a los que llama en diversas fases de su ciclo de vida (al crearse el applet, al redibujarse, al destruirse...). Si deseamos que nuestro applet haga cosas especiales en esos momentos deberemos sobreescribir esos métodos.

Métodos del applet.

void init() Este método se llama al crearse el applet y sólo se ejecuta esa vez. Se suele utilizar para inicializar variables globales.

void .smrtf) Se llama cuando hay que activar el applet. Esto sucede cuando el applet se ve en la pantalla. Se suele utilizar para comenzar las actividades de applet, ya que en general éste debe estar visible en la pantalla para poder realizar su función.

void .stop() Es el inverso del anterior. Es llamado cuando el applet deja de estar visible. Se suele utilizar para interrumpir las actividades activadas en start().

void destroJyJ Método llamado al destruirse el applet. Normalmente no se suele sobreescribir, ya que la destrucción del applet conlleva la destrucción de todo lo que se ha creado en él. Puede ser útil para mostrar una ventana de confirmación que pregunte al usuario si de verdad debe cargarselo.

void repainto Este método no debería ser sobrecargado y es llamado cuando se necesita redibujar el applet. Podemos llamarlo nosotros desde nuestro código. Llama a update(Graphics).

void zlpdcrte(Grcrphic.Q Llamado por repaint() cuando se necesita actualizar el applet. Su implementación borra el rectángulo y llama a paint() para volver a pintarlo.

void pnint(Gr0phics) Método en el que se dibuja el applet y el cual deberemos sobreescribir para poder dibujar lo que nosotros deseemos..

void print(Grcrphics) Equivalente a painto pero es llamado cuando se va a imprimir el contenido del applet.

El siguiente ejemplo conviene observarlo desde un navegador e ir viendo los distintos mensajes que nos muestra el applet, para comprender cuando son llamados los métodos:

/**Archivo CicloDeVida.java ** Applet CicloDeVida ** <APPLET CODE="CicloDeVida.class" WIDTH="lOO" HEIGHT="400"></APPLET> */

import java.applet.Applet; import java.awt.Graphics;

public class CicloDeVida extends Applet { String mensajes;

public void init() {

f mensajes = "Inicializando. 'I;

public void start() {

1 escribirMensaje("Método s t a r t . 'I);

public void stop() {

1 escribirMensaje("Mét0do stop. ");

I

30

public void destroy0 {

} escribirMensaje("Destruyend0 Applet. ");

void escribirMensaje(String nuevoMensaje) { mensajes += nuevoMensaje; repaint();

1

public void paint(Graphics g) { g.drawString(mensajes, 5, 15);

1

Etiqueta APPLET.

La etiqueta APPLET presenta varios parámetros, de los cuales sólo es obligatorio poner los ya comentados CODE, WIDTH y HEIGHT. Son los siguientes:

CODE Nombre completo (incluyendo extensión) del fichero que contiene el applet.

WIDTH Anchura del rectángulo donde se ejecutará el applet.

HEIGHT Altura del rectángulo donde se ejecutará el applet.

CODEBASE f . - . ' Dirección donde está el fichero.class que contiene al applet. Es necesario ponerlo cuando el

f CODE no puede contener dlrectorios, sólo el nombre del fichero. applet se encuentra en un directorio distinto al de la página desde la que se le llama, ya que

ALT Algunos navegadores comprenden la etiqueta APPLET pero no pueden mostrar applets. Esto es debido a no tener instalada la máquina virtual Java, o a que son navegadores en modo texto. En ese caso mostrarán el contenido de este parámetro en lugar del applet.

Hay algunos m& pero de poca importancia.

Paso de parámetros.

Entre <APPLET> y </APPLET> podremos colocar etiquetas PARAM que nos permitirán pasar parámetros al applet. Tienen dos atributos:

VAL UE

NAME Nombre del parámetro.

Valor del parámetro.

Podemos obtener esos valores por medio del método getParameter(String), corno vemos en el siguiente ejemplo:

/**Archivo MostrarMensaje.java * Applet MostrarMensaje * <APPLET CODE="MostrarMensaje.class" WIDTH="200" HEIGHT="70"> * <PARAM NAME="Mensaje" VALUE="Mi mensaje propio"> * </APPLET> *I

import java.applet.Applet; import java.awt.*;

public class MostrarMensaje extends Applet {

String mensaje;

public void inito { mensaje = getParameter("Mensaje");

t

225930

public void paint(Graphics g) { g,drawString(mensaje,20,20);

} 1

Hay que destacar que Java no distingue entre mayúsculas y minilsculas en cuanto al nombre de los parámetros.

En muchos casos, el usuario puede que no incluya parámetros que consideramos necesarios o que escriba mal el nombre de un parámetro. En ese caso, la llamada a getparameter() nos devolverá null. Debemos tener cuidado con esto, ya que nos pueden saltar excepciones por esta clase de cosas. Así pues, el código correcto de init() será:

public void init0 {

mensaje = getParameter("Mensaje"); if (mensaje==null)

mensaje = "Mensaje por defecto"; I

De este modo, si nos equivocamos en la etiqueta PARAM, nos mostrará un mensaje y no lanzará ninguna excepción.

Ejecución multihilo (Multithread) en applets.

Hasta ahora sólo disponíamos de un hilo de ejecución. Es decir, en nuestros programas sólo se ejecuta una cosa o tarea a un tiempo. Si deseamos que se ejecuten varias cosas a la vez o simplemente deseamos disponer de una manera precisa de controlar la ejecución de parte de nuestro programa dependiendo del tiempo, necesitaremos que nuestro applet realice una ejecución multihilo.

El concepto de multitarea es diferente al de multihilo. El primero se suele aplicar a la ejecución concurrente de programas distintos, ya que para que exista multitarea se exige que cada proceso ejecutándose disponga de su propio espacio en la memoria. En el segundo caso, en cambio, todos los hilos que se ejecutan concurrentemente disponen del mismo espacio de memoria.

. 32

Pero no vamos a escribir un tratado filosófico sobre las diversas formas de programación concurrente. Lo mejor que podemos hacer es explicarlo sobre un ejemplo. El ejemplo siguiente es una modificación del applet MostrarMensaje, realizado anteriormente, que realiza un scroll lateral del texto, que aparece por la derecha y desaparece por la izquierda. El código nuevo que concierne a la ejecución multihilo está en negrita para facilitar su identificación:

/*Archivo MostrarCadena.java * Applet MostrarCadena * * <APPLET CODE="MostrarCadena.class" WIDTH="200" HEIGHT="200"> * <PARAM NAME="Cadena" VALUE="Esto sí que esta bien"> </APPLET> *I .

import java.applet.Applet; import java.awt.*;

public class MostrarCadena extends Applet implements Runnable { String mensaje;

int lugar; Thread hilo = null;

public void init0 { mensaje = getParameter("cadena"); if (mensaje"lml1) mensaje = "Mensaje por defecto";

lugar = getBounds0.width; 1

public void start0 { if (hilo==null) { hilo = new Thread(this); hilo.start0;

1 > I

public void stop0 {

1 hilo = null;

public void paint(Graphics g) {

1 g,drawString(mensaje,lugar,20);

public void run0 f while (hilo!=null && hilo.isAlive0) {

lugar -= 1 ; repainto; try

f catch (InterruptedException e) f // No hacemos nada

f

hilo.sleep(20);

I <

1

Lo primero es aseguramos que nuestro applet implementa el interfaz Runnable, necesario para el soporte de threads, o hilos de ejecución. Después declaramos un objeto de tipo Thread, es decir, hilo, y lo igualamos a null. En el método starto, que es donde debe estar todo el código de inicialización, creamos el hilo y lo arrancamos llamando a su método start(). En stop(), por el contrario, lo paramos.

El método run() es nuevo y es consecuencia de la impiementación del interfaz Runnable. Cuando creamos un hilo de ejecución, como hemos hecho en starto, el hilo recién creado siempre comienza su vida irtil ejecutando el método run(). Así pues, aquí estará el código del hilo.

Comenzamos preguntando si existe nuestro hilo (hilo!=null) y si está ejecutandose (isAlive).

Luego mueve el texto un poco a la izquierda, repinta, y se obliga a sí mismo a dejar de ejecutarse durante 10 milisegundos por medio del método sleep(). Transcurrido ese tiempo seguirá su ejecución por el mismo sitio donde la dejó (de ahí que sea necesario el while).

Por último es obligatorio capturar la excepción IntermptedException para poder llamar al método sleep(). En caso contrario el compilador genera mensajes de error y advertencia. Así pues, lo hacemos, aunque no especifiquemos ningún código en caso de que se lance dicha excepción. Esto ocurrirá en casos muy excepcionales, por lo que no debemos preocupamos.

Servlets

Hasta hace poco, JAVA se utilizaba básicamente para dotar a las páginas WEB de una mayor interactividad mediante los Applets, y por tanto solo actuaba sobre el lado Cliente. Pero el lado Servidor también puede beneficiarse de todas las ventajas que ofrece JAVA, gracias a los Servlets .

Los Servlets se diferencian de los Applets básicamente en que se ejecutan en el Servidor y en que no presentan ningún tipo de interfaz gráfica puesto que están totalmente controlados por un servicio de red como pudiera ser un Servidor Web. Abordaremos pues la programación de Servlets en un entorno Cliente/Servidor basado en http, de hecho, este es uno de sus aspectos más interesantes, y es por lo que muchos programadores que hasta ahora utilizaban CGI's (Common Gateway Interface), están utilizando Servlets. Hasta ahora los CGI's eran el ilnico medio de proporcionar interacción entre el Cliente y el Servidor. Un ejemplo muy común de uso de los CGI's son los típicos formularios que el usuario ha de rellenar con sus datos personales, que posteriormente pasan a formar parte de una base de datos.

i Porqué se los Servlets son mejores que los CGI's ?

A continuación se enumeran algunas de las razones que evidencian este hecho:

. Se programan utilizando un A P I estandarizada JAVA, y por tanto se benefician de todas las ventajas de este potente lenguaje.

. Consumen menos recursos que los CGI's y los Fast-CGI's. Por ejemplo no es necesario cargarlos en memoria tantas veces como peticiones de ejecución existan.

. Se pueden cargar indiferentemente y de forma transparente tanto desde un disco local como desde una dirección remóta, de forma totalmente transparente. Responden a la nueva filosofia de software distribuido.

34

Los Servlets pueden comunicarse entre sí, y por tanto, es posible una resignación dinámica de la carga de proceso entre diversas máquinas. Es decir, un servlet podría pasarle trabajo a otro servlet residente en otra máquina.

- Poseen una estructuración en los fuentes mucho más clara que los CGI's (especialmente si esta comparación se efectúa con respecto a PERL).

* Se pueden reutilizar CGI's ya hechos, incrustándolos en Servlets.

. Es posible utilizarlos en Servidores tan populares como el Apache, el Fastracker ó el Internet Information Server.

Los Servlets son la mejor opción a partir de ahora para desarrollar aplicaciones para Servidores WEB. Trabajan de forma transparente con las fílosofias GET y POST de los formularios HTML, y también como es lógico, se entienden perfectamente con los Applets, pero también se pueden entender con Clientes programados en cualquier otro lenguaje.

Aplicaciones de los Servlets

Con los Servlets se puede implementar por ejemplo:

- Típicos sistemas que hasta ahora únicamente se implementaban con CGI's. Para consultar las Bases de Datos, los Servlets pueden utilizar JDBC (Java Data Base Connection), lo que les permite extraer información de cualquier sistema de Base de Datos.

. Automatización de un sistema de recepción y publicación de información. Por ejemplo podríamos montamos una simple estación meteorológica que permitiese acceso a su información mediante una página WEB. Por un lado tendríamos un servlet que recolectaría la información de los diversos tipos de sensores y la almacenaría en bases de datos, y por otro lado, un servlet que se encargaría de presentar esta información en función de las peticiones del Cliente basándose en estas mismas bases de datos.

Control de la recepción de e-mails, y de sistemas de news, chats, etc. Conviene recordar que Java está especialmente indicado para la programación utilizando los protocolos TCPAP (SMTP, NNTP, conexiones socket, etc).

. Obviamente pueden generar páginas HTML en el Cliente de forma dmámica.

* Dado que pueden manejar múltiples peticiones concurrentemente, es posible implementar aplicaciones colaborativas, como por ejemplo una aplicación de videoconferencia.

- Se pueden implementar agentes inteligentes que interactuen entre ellos.

Y la lista sigue . . . .

Mi primer Servlet

Para poder hacerse una idea del funcionamiento de un servlet y del aspecto que tienen los mismos, lo mejor es estudiar un ejemplo sencillo. Imagínese que en una página web se desea recabar la opinión de un visitante así como algunos de sus datos personales, con el fin de realizar un estudio estadístico. La primera tarea seria diseñar un formulario en el que el visitante pudiera introducir los datos. Este paso es idéntico a lo que se haría al escribir un programa CGI, ya que bastará con utilizar los tags que proporciona el lenguaje HTML (<FORM>, <ACTION>, <TYPE>, etc.).

Instalacion del Java Servlet Development KIT (JSDK 2.0)

Para poder ejecutar este ejemplo es necesario que el JSDK 2.0 esté correctamente instalado; para realizar esta instalación se pueden seguir los siguientes pasos:

1. En primer lugar se debe conseguir el archivo de instalación, llamado jsdk2O-win32. eve. Este archivo se puede obtener de http://www.javasoft.com/products/servlet/index.html. Se trata de un archivo de 950 Kbytes, que puede ser transportado en un disquete sin dificultad.

2. Se copia el archivo citado al directorio CATemp de la propia computadora. Se hace doble click sobre dicho archivo y comienza el proceso de instalación.

3. Se determina el directorio en el que se realizará la instalación. El programa de instalación propone el directorio C:\Jsclk2.0, que es perfectamente adecuado.

4. En el directorio C:\Jsdk2.0\hin aparece la aplicación servletrunner.exe, que es muy importante. Para que esta aplicación sea encontrada al teclear su nombre en la ventana de MS-DOS es necesario que el nombre de dicho directorio aparezca en la variable de entorno PATH.

Una posibilidad es modificar de modo acorde dicha variable y otra copiar el archivo sendetrunner.exe al directorio donde están los demás ejecutables de Java (por ejemplo CVdk2.2. nbin); como ese directorio ya está en el PATH, la aplicación servletrunner.exe será encontrada sin dificultad. Ésta es la solución más sencilla. Además de encontrar sersletrunner.exe, tanto para compilar los servlets como para ejecutarlos con servletrunner es necesario encontrar las clases e interfaces del M I de JSDK 2.0. Estas clases pueden estar por ejemplo en el archivo C:\Jsdk2.Oll¿bljsd~.jar.

5 . Para que este archivo pueda ser localizado, es necesario modificar la variable de entorno CLASSPATH. Esto se puede hacer en la forma (antepone el path del fichero jsdk.jar al valor anterior que se tuviera en la variable CLASSPATH):

set CLASSPATH=C:Vsdk2.OUib\jsdk.jar;%CLASSPATH%

Ejemplo: FORMULARIO

El formulario contendrá dos campos de tipo TEXT donde el visitante introducirá su nombre y apellidos. A continuación, deberá indicar la opinión que le merece la página visitada eligiendo una entre tres posibles (Buena, ReguIar y Mala),. For último, se ofrece al usuario la posibilidad de escribir un comentario si así lo considera oportuno. A continuación puede observarse el diseño del formulario creado; el código correspondiente a la phgina HTML que contiene este formulario es el siguiente

<Archivo MiServlet.html> <HTML> <HEAD> <TITLE>Envíe su opinión</TITLE> </HEAD> <BODY> <H2>Por fhvor, envíenos su opinión acerca de este sitio web</H2>

36

<FORM ACTION="http://lis.uam.mx:8080/servlet/ServletOpinion"METHOD="POST~

Nombre: <INPUT TYPE="TEXT" NAME="nombre" SIZE=lS><BR> Apellidos: <INPUT TYPE="TEXT" NAME="apellidos" SIZE=30><P> Opinión que le ha merecido este sitio web<BR> <INPUT TWE="RADIO" CHECKED NAME="opinion" VALUE="Buena">Buena<BR> <INPUT TYPE="RADIO" NAME="opinion" VALUE="Regular">Regular<BR> <INPUT TYPE="RADIO" NAME="opinion" VALUE="Mala">Mala<P>

Comentarios <BR> <TEXTAREA NAME="comentarios" ROWS=6 COLS=40>

<INPUT TYPE="SUBMIT" NAME="botonEnviar" VALUE="Enviar"> <INPUT TYPE="RESET" NAME="botonLimpiar" VALUE="Limpiar"> </FORM> </BODY> </HTML>

</TEXTAREA><P>

En el código anterior, hay algunas cosas que merecen ser comentadas. En primer lugar, es necesario asignar un identificador Único (es decir, un valor de la propiedad NAME) a cada uno de los campos del formulario, ya que la información que reciba el servlet estará organizada en forma de pares de valores, donde uno de los elementos de dicho par será un String que contendrá el nombre del campo.

Así, por ejemplo, si se introdujera como nombre del visitante "Miguel", el sendet recibiría del browser nombre=Miguel, que permitirá acceder de una forma sencilla al nombre introducido mediante el método gdParameter0, tal y como se explicará posteriormente al analizar el servlet. Por este motivo es importante no utilizar nombres duplicados en los elementos de los formularios. Por otra parte puede observarse que en el tag <FORM> se han utilizado dos propiedades, ACTION y METHOD. El método (METHOD) utilizado para la transmisión de datos es el método HTTP POST. También se podría haber utilizado el método HTTP GET, pero este método tiene algunas limitaciones en cuanto al volumen de datos transmisible, por lo que es recomendable la utilizar el m&odo POST. Mediante la propiedad ACTION deberá especificarse el URL del servlet que debe procesar los datos. Este URL contiene, en el ejemplo presentado, las siguientes características:

El servlet se encuentra situado en un Servidor cuyo nombre es lis.uamm. Este nombre dependerá de la computadora que proporcione los servicios de red. La fomla de saber cuál es el nombre de dicha computadora y su dirección IP es acudiendo al Panel de Control (Control Panel) de Windows. Clicando en Red (Network), se accede a las propiedades de la red (obviamente, si se quiere utilizar servlets, será necesario tener instalados los drivers de red, en concreto los drivers de TCPLP que vienen con windows 95/98AVT). Dentro de la lengüeta Protocolos (Protocols) se escoge TCPflP y se clica en Propiedades (Properties). Aparecerá un nuevo cuadro de diálogo en el que habrá que seleccionar la lengüeta DNS (Domain Name Svstem). Allí se encuentra recogido el nombre de la computadora anfitrión (Host Name) así como su dominio (Domain Name). En cualquier caso, para poder hacer pruebas, se puede utilizar el como nombre de Servidor el host local o localhost, cuyo número IP es 127.0.0.1. Por ejemplo:

<FORM ACT1ON="http://localhost:SOSO/servl~/ServletOpinion" METHOD="POST">

o de otra forma,

<FORM ACT1ON="http://127.0.0.1:8080/servlet/ServletOpinion" METHOD="POST">

,

37

El Servidor HTTP está "escuchando" por el puerto el puerto 8080. Todas las llamadas utilizando dicho puerto serán procesadas por el módulo del Servidor encargado de la gestión de los semlets. En principio es factible la utilización de cualquier puerto libre del sistema, siempre que se indique al Servidor HTTP cuál va a ser el puerto utilizado para dichas llamadas. Por diversos motivos, esto último debe ser configurado por el administrador del sistema.

El servlet se encuentra situado en un subdirectorio (virtual) del Servidor llamado semlef. Este nombre es en principio opcional, aunque la mayoría de los Servidores lo utilizan por defecto. En caso de querer utilizar otro directorio, el Servidor debe ser configurado por el administrador para tal fin. En concreto, la aplicación senletrunner de Sun no permite dicha modificación, por lo que el URI, utilizada debe contener dicho nombre de directorio.

El nombre del sendef empleado es SenlefOpinion, y es éste el que recibirá la información enviada por el Cliente al Servidor (el formulario en este caso), y quien se encargará de diseñar la respuesta, que pasará al Servidor para que este a su vez la envíe de vuelta al Cliente. Al final se ejecutará una clase llamada ServletOpinion.class.

Código del Servlet

Tal y como se ha mencionado con anterioridad, el servlet que gestionará toda la información del formulario se llamará ServlefOpinion. Como un servlef es una clase de Java, deberá por tanto encontrarse almacenado en un fichero con el nombre Servlet0pinion.java. En cualquier caso, por hacer lo más simple posible este ejemplo introductorio, este servlef se limitará a responder al usuario con una página HTML con la información introducida en el formulario, dejando para un posterior apartado el estudio de cómo se almacenarían dichos datos.

:;Arhchivo Sew1etOpinion.jrrvn :

import java.io. *; import javax.servlet.*; import javax.servlet.http.*;

public class ServletOpinion extends HttpServlet f

// Declaración de variables miembro correspondientes a // los campos del formulario private String nombre=null; private String apellidos=null; private String opinion=null; private String comentarios=null;

// Este método se ejecuta una única vez (al ser inicializado el servlet) // Se suelen inicializar variables y realizar operaciones costosas en //tiempo de ejecución (abrir ficheros, bases de datos, etc)

public void init(Serv1etConfig config) throws ServletException {

// Llamada al método init() de la superclase (GenericServlet) // Así se asegura una correcta inicialización del servlet super.init(config); System.out.println("1niciando ServletOpinion ...'I); ) // fin del método init()

// Este método es llamado por el Servidor web al "apagarse" (al hacer

38

// shutdown). Sirve para proporcionar una correcta desconexión de una // base de datos, cerrar archivos abiertos, etc. public void destroy() { System.out.println("No hay nada que hacer..."); } fin del método destroy()

// Método llamado mediante un HTTP POST. Este método se llama // automáticamente al ejecutar un formulario HTML public void doPost (HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {

// Adquisición de los valores del formulario a través del objeto req nombre=req.getParameter("nombre"); apellidos=req.getParameter("apellidos"); opinion=req.getParameter("opinion"); comentarios=req.getParameter("comentarios");

//Devolver al usuario una página HTML con los valores adquiridos devolverPaginaHTML(resp); } // fin del método doPost0 public void devolverPaginaHTML(Serv1etResponse resp) {

// En primer lugar se establece el tipo de contenido MIME de la respuesta resp.setContentType("text/html");

// Se obtiene un Printwriter donde escribir (sólo para mandar texto) Printwriter out = null; try I out=resp.getWriter(); } catch (10Exception io) { System.out.println("Se ha producido una excepcion"); 1

// Se genera el contenido de la página HTML out.println("<html>"); out.println("<head>"); out.println("<title>Valores recogidos en el formuIario</title>"); out.println("</head>"); out.println("<body>"); out.println("<b><font size=+2>Valores recogidos del 'I);

out.println("formulario: </font></b>"); out.println("<p><font size=+ l><b>Nombre: </b>"+nombre+"</font>"); out .println("<br><fontsize=+l ><b>Apellido: </b>" +apellidos+"</font><b><font size=+ 1 ></font></b>"); out.println("<p><font size=+l> <b>Opini&oacute;n: </b><i>" + opinion + "</i></font>"); out.pnntln("<br><font size=+] >+>Comentarios: a>" + comen~rjos +"</font>"); out.println("</body>"); out.println("</html>");

// Se fuerza la descarga del buffer y se cierra el Printwriter, // liberando recursos de esta forma. IMPORTANTE out.flush0; out.close();

} // fín de devolverPaginaHTML()

// Función que permite al Servidor web obtener una pequeña descripción del // servlet, qué cometido tiene, nombre del autor, comentarios // adicionales, etc. public String getServletInfoO f return "Este servlet lee los datos de un formulario" + 'I y los muestra en pantalla"; } // fin del método getServlethfo() 1 f

En aras de una mayor simplicidad en esta primera aproximación a los servlefs, se ha evitado tratar de conseguir un código más sólido, que debería realizar las comprobaciones pertinentes (verificar que los Sfring no son null después de leer el parámetro, excepciones que se pudieran dar, etc.) e informar al usuario acerca de posibles errores en caso de que fuera necesario.

En cualquier caso, puede observarse que el aspecto del código del servlef es muy similar al de cualquier otra clase de Java. Sin embargo, cabe destacar algunos aspectos particulares:

La clase ServlefOpinion hereda de la clase HttpServfet, que a su vez hereda de GenericServlet. La forma más sencilla (y por tanto la que debería ser siempre empleada) de crear un servlet, es heredar de la clase HttpServlef. De esta forma se está identificando la clase como un servlef que se conectará con un Servidor HTTP.

Ciclo de vida del Servlet (explicación del código)

El método inif0 es el primero en ser ejecutado. Sólo es ejecutado la primera vez que el servlef es llamado. Se llama al método init0 de la super-clase Generidervfet a fin de que la inicialización sea completa y correcta. La interface ServfetConfig proporciona la información que necesita el servlef para inicializarse (parámetros de inicialización, etc.).

El método Clesfroyo no tiene ninguna h c i ó n en este servfet, ya que no se ha utilizado ningún recurso adicional que necesite ser cerrado, pero tiene mucha importancia si lo que se busca es proporcionar una descarga correcta del servlef de la memoria, de forma que no queden recursos ocupados indebidamente, o haya conflictos entre recursos en uso. Tareas propias de este método son por ejemplo el cierre de las conexiones con otras computadoras o con bases de datos.

Como el formulario HTML utiliza el método HTTP POST para la transmisión de sus datos, habrá que redefinir el método doPosf0, que se encarga de procesar la respuesta y que tiene como argumentos el objeto que contiene la petición y el que contiene la respuesta (pertenecientes a las clases HffpServfetRequesf y HffpServletResponse, respectivamente). Este método será llamado tras la inicialización del servlet (en caso de que no haya sido previamente inicializado), y contendrá el núcleo del código del servlet (llamadas a otros servlefs, llamadas a otros métodos, etc.).

El método getServIefInfo0 proporciona datos acerca del servlet (autor, fecha de creación, funcionamiento, etc.) al Servidor web. No es en ningún caso obligatoria su utilización aunque puede ser interesante cuando se tienen muchos servfets hncionando en un mismo Servidor y puede resultar compleja la identificación de los mismos. % Por último, el método devofverPaginaHTML0 es el encargado de mandar los valores recogidos del Cliente. En primer lugar es necesario tener un stream hacia el Cliente (PrintWriter cuando haya que mandar texto, ServlefOufpufSfream para datos binarios). Posteriormente debe indicarse el tipo de contenido MIME de aquello que va dirigido al Cliente

. 40

( ta th tml en el caso presentado). Estos dos pasos son necesarios para poder enviar correctamente los datos al Cliente.

Puede sorprender la forma en que ha sido enviada la página HTML como String. Podria parecer más lógico generar un String en la forma (concatenación de Strings), String texto="<html><head> + . . . +"<b>Nombre:</b>" + nombre + "</font>. .. y después escribirlo en el stream o flujo de salida. Sin embargo, uno de los parámetros a tener en cuenta en los sentlets es el tiempo de respuesta, que tiene que ser el mínimo posible. En este sentido, la creación de un String mediante concatenación es bastante costosa, pues cada vez que se concatenan dos Strings melante el signo + se están convirtiendo a StringBu-ms y a su vez creando un nuevo String, lo que utilizado profusamente da lugar requiere más recursos que lo que se ha hecho en el ejemplo, donde se han escrito directamente mediante el método printlno. El esquema mencionado en este ejemplo se repite en la mayoría de los servlets y es el fundamento de ésta tecnología.

JMF : Java Media Framework API Guide

JMF A P I 2.0 permite desarrollar programas en Java que presenten, manipulen, procesen, transmitan y reciban medios como audio, video o ambos en un ambiente orientado a objetos. Tomando ventajas de la plataforma Java, JMF cumple con la promesa de 'Write Once, Run Anyware". Proporciona una arquitectura unificada y protocolos de mensajes para manejar la adquisición, procesamiento y entrega de medios que dependen del tiempo. JMF esta diseñado para soportar diversos tipos de contenido en medios como formato AIFF, AU, AVI, MIDI, MPEG, Quick Time, RMF y WAV, además de permitir el desarrollo e implementación de nuevos formatos de compresión de señal y esquemas de entrega y presentación de medios.

Medios que dependen del tiempo

Cualquier dato que tenga un cambio representativo con respecto al tiempo puede ser caracterizado como medio que depende del tiempo. Dentro de esta breve defmición se encuentran, por ejemplo, los audio clips, secuencias MIDI, movie clips, y desarrollos multimedia entre otros.

Una característica de los medios dependientes del tiempo (Streamming Media: medios que .fluyen continuamente) es que requieren de un determinado tiempo para su entrega y presentación. Una vez que el flujo de datos comienza existe un tiempo bien determinado de entrega que debe ser conocido para cada trama en témunos de la recepción y la presentación de los datos. El formato en el cual los datos son ordenados lo llamaremos tipo de contenido (Conrent Type). QuickTime, MPEG, y WAV son ejemplos de Confent g'pe. Content ~ p e es en esencia el tipo de archivo usado.

Un flujo de datos (media stream) es el flujo de datos obtenido desde u archivo local, de la red o capturado desde una cámara o un micrófono. Un Media Stream comúnmente contiene múltiples canales de datos llamados Tracks. Por ejemplo un archivo QuickTime podna contener un track de audio y uno de video. Un medin stream que contiene múltiples tracks son llamados mulitplexados o complejos. Demultiplexar será entonces el proceso de extraer los track individuales de un media stream conlplejo.

Un tipo de track (track hpe) identifica el tipo de datos que contiene el media srrenm, como audio o video. El formato de un track define la estructura del track.

Un mediastream puede ser identificado por su ubicación y por el protocolo usado para accesarlo. Por ejemplo un URL podría ser usado para describir la ubicación de un archivo QuicktTime en un sistema local o remoto. Si el archivo es local, puede ser accesado a través de 1 protocolo FILE. De otro modo si esta sobre un Servidor de Web, el archivo puede ser accesado a través de I protocolo HTTP. Un Media loacrrtor proporciona un camino para identificar la ubicación de un medza stream cuando un URL no puede ser usado.

Un media stream puede clasificarse en función de como los datos son entregados:

o Pull La transferencia es iniciada y controlada desde el lado del Cliente. Por ejemplo HTTP y FILE

O Push EL Servidor inicia la transferencia de datos y controla el flujo de los paquetes. RTP es un protocolo que utiliza este modelo, similarmente SGI MediaBase es un protocolo usado para Video sobre demanda (VOD).

Modelo de Referencia

Definamos entonces un modelo (ver Figura 11) que represente como es el procesamiento de un medio que depende del tiempo, que nos servirá como base para el desarrollo de nuestra implementación.

Input Process Output

Figura 1 l . Modelo referencia

Observemos en la figura anterior, cómo esta estructurado nuestro modelo; a la entrada podemos considerar cualquiera de las tres fhentes mostradas como entrada de datos; un dispositivo de captura de voz como un micrófono, nos entregara la señal en banda base, es decir, señal sin haber pasado a través de ningún formato; un archivo de datos, puede o no entregar información con algún formato, inclusive puede contener varios tracks como lo mencionábamos anteriormente; por último, la red entregara un streaming media con la información pertinente del formato de cada uno de los tracks que contenga (si tiene varios claro).

42

Una vez que las fuentes han sido definidas, los datos (como el audlo y el video), pueden ser presentados a través de dispositivos de salida como un par bocinas o un monitor. Además de poder entregar los datos a estos dispositivos, la arquitectura de JMF nos permite enviar los datos a otros destinos, por ejemplo, salvar la información en un archivo o transmitirlo a través de una red. En esta arquitectura, un destino de salida para datos es a veces llamado Data Sink.

Un intérprete (renderer) es una abstracción de un dispositivo para la presentación de un medio. Para audio por ejemplo, el dispositivo para presentar el audio es comúnmente la tarjeta de sonido de una computadora que tiene como dispositivos de salida un par de bocinas. Para video, el dispositivo de presentación es típicamente el monitor de la computadora.

En muchos casos, el flujo de datos debe ser manipulado antes de ser presentado al usuario; generalmente una serie de operaciones de procesamiento ocurren antes de la presentación.

1. Si el flujo de información esta multiplexado, los tracks individuales son extraídos. 2. Si los tracks individuales están codificados, son entonces decodificados. 3. Si es necesario, los tracks son convertidos a un formato o formatos diferentes. 4. Filtros y efectos son aplicados para mejorar la calidad del track (si se desea).

Los tracks son entonces entregados a un dispositivo de salida apropiado. Si el media stream esta siendo almacenado en algún lugar o reenviado a un dispositivo de salida, las etapas del procesamiento podrían diferir significativamente.

Por ejemplo: si se quiere capturar audlo y video desde una video camara, el proceso del dato será el siguiente:

l . Los tracks de audio y video deben ser capturados. 2. Los efectos de filtros podrían ser aplicados a la señal en banda base (si se desea). 3. Los tracks individuales deben ser codificados. 4. Los tracks codificados deben ser multiplexados en un sencillo paquete (media stream). 5 . El media stream podrá ser salvado a un archivo entonces.

Tipos de Contenido y Formatos

Las siguientes tablas (ver Figura 12 y Figura 13) identifican algunos de las características de formatos comunes. Cuando se seleccione un formato es importante tomar en cuenta las caracteristicas del formato, el ambiente que lo soportara y las expectativas de audiencia. Por ejemplo, si se entregaran medios a través de Internet, se deberá tener especial atención en el ancho de banda requerido.

Los requerimiento de CPU caracterizan el poder de procesamiento necesario para una optima presentación del formato especifico. El ancho de banda caracteriza la velocidad de transmisión necesaria para enviar o recibir los datos con la suficiente fluidez ó rapidez para una presentación optima.

Requirements

Cinepak

MPEG-1 I MPEG / H i g h 1 High High

H.261 rFre H.263

QuickTime

JPEG

hdeo I QuickTime AV1 I=[ Medium [ Medium Figura 12. Formatos de Video

Format r.--" Content Type

AVI

WAV PCM QuickTime

I AVI

Mu-Law I $AV ulckTime

I R P MPEG-1 I MPEG

Layer3

GSM IRTP WAV

G.723.1 r'

Quality I CPU Requirements

High Low

Low Low

High 1 High '"

High 1 High

"- Medium Medium

Requirements

High

High

High

Medium I

Low 1 Low I

Figura 13. Formatos de Audio.

Algunos formatos son diseñados para aplicaciones y requerimientos particulares. Los formatos de Gran Ancho de Banda y Alta Calidad son generalmente utilizados para usar aplicaciones con CD-ROM o fuentes locales. El H.261 y H.263 son generalmente usados para aplicaciones de videoconferencias y son optimizados para video donde no existe demasiado movimiento. Similarmente, el G.723 es comúnmente usado para producir una tasa de transferencia (Bit-Rate) baja para aplicaciones de telefonía.

44

Arquitectura JMF

Para entender como h c i o n a la arquitectura en la cual desarrollaremos nuestra aplicación, tomemos u11 ejemplo muy común. Imaginemos un dispositivo t a l como un video cassette y una video casetera (VCR), los cuales nos proporcionan un modelo familiar para grabar, procesar y presentar medios dependientes del tiempo. Ahora bien, cuando vemos una película utilizando nuestra VCR, nosotros proporcionamos el flujo de datos (media stream) a la VCR insertando el video cassette; de tal manera que la VCR lee e interpreta los datos en el video cassette y envía la correspondiente señal a la televisión y a las bocinas.

Video camera \ /

Output Devlces r'Fsstination)

Figura 14. Arquitectura JMF

De la misma manera, JMF usa este mismo modelo básico. Una hente de datos (data source) encapsula el medin stream tal como lo tenemos en un video cassette y un dispositivo llamado player proporciona los mecanismos de procesamiento y control similares a una VCR.

Esta demás decir que para poder capturar y ejecutar audio y video con JMF se requieren los apropiados dispositivos de entrada y salida tales como micrófonos, cámaras, bocinas y monitores.

Modelo de Tiempo

JMF proporciona una precisión de del orden de nanosegundos para el tratamiento de sus medios. Un punto en particular en el tiempo esta representado por un objeto tiempo(Time), a través del cual algunas clases soportan la especificación en nanosegundos.

Las clases que soportan el modelo de tiempo de JMF implementan un reloj (Clock) para mantener el tiempo de truck de un particular media stream. La interfaz Clock define el tiempo y las operaciones de sincronización que se necesitan para el control de la presentación.

Un Clock. usa un tiempo base (Timehnse) para mantener el paso de tiempo de un track, mientras un medin .stream esta siendo presentado. Un TimcBuse proporciona un reloj, t a l como un oscilador de cristal en un reloj.

La única información que un Time Base proporciona es el tiempo actual, el cual esta referido como time-hase rime. El time-base time no puede ser detenido o reiniciado. El time-base time esta basado en el reloj del sistema.

Un objeto Clock, representa la posición actual de un media .stream- el comienzo del stream es el tiempo cero, el final del .stream es el tiempo máximo del media stream. La duración del media stream es el tiempo desde que comienza hasta que termina. Los objetos de esta clase implementan la interfaz Duration. si es que se puede reportar la duración del media stream.

Para mantener al track con el tiempo actual del medio (MediaTime), un reloj (Clock) usa:

- El tiempo de inicio de la base de tiempo: el tiempo que reporta el Timehase cuando la presentación comienza.

- La taza de ejecución: esto es, que tan rápido esta corriendo el Clock en relación al Timebase. La taza (rate) es un factor de la escala que es aplicación al Timebase. Por ejemplo, un rate de 1 .O, representa la taza de ejecución normal de un medio, mientras que un rate de 2.0 indica que la presentación correrá a dos veces la taza normal. Una negativa indica que el Clock esta corriendo en dirección opuesta a la del Timehase, sin embargo una implementación de este tipo podría ser usado para tocar un mediastream al revés.

Cuando la presentación comienza, el tiempo del medio es mapeado con el tiempo time-hose (time-base time), y el avance del time-base es usado para medr el paso del tiempo. Durante lapresentación, el tiempo actual del medio es calculado usando la siguiente formula:

MediaTime = MediaStrattime+ Rate flimeBaseTime-TimeBaseStratTime)

Cuando la presentación se detiene, el tiempo' se detiene, pero el tiempo base continua su avance. Si la presentación es reiniciada, el tiempo de medio es remapeado al actual tiempo base.

Manejadores (Managers)

El JMF A P I consiste en el manejo de interfaces que definen el desempeño y la interacción de objetos usados para capturar, procesar y presentar los medios. Las implementaciones de estas interfaces operan junto con la estructura de Framework. Usando objetos intermediarios llamados managers. JMF hace más fácil integrar nuevas implementaciones de interfaces que pueden ser usadas del mismo modo que otras interfaces con las existentes clases.

La arquitectura usa cuatro manejadores

- Manager: maneja la construcción de players, Processors, DataSources y Data Sinks. Este nivel permite nuevas implementaciones para ser integradas similarmente con JMF. Desde la perspectiva del Cliente, estos objetos siempre son creados del mismo que cualquier objeto en cualquier otra clase.

- PackageManager: Mantiene un registro de los packages que contienen las clases de JMF como Players. Processors. DataSowce y DataSinks.

- CaptureDeviceManager: mantiene un registro de los dispositivos de captura disponibles.

- PluglnManager: mantiene el registro de los plug-in disponibles en JMF, tales como, Multiplexers, Demultiplexers, Codecs, Ejfects y Renderers.

46

Conclusiones

El uso de técnicas orientadas a objetos permite el desarrollo de sistemas compuestos por elementos perfectamente definidos, haciendo de ellos agentes independientes. Esto nos recuerda la definición de protocolos, entidades modulares independientes, que reaccionan mediante secuencias normalizadas de datos que definen el intercambio de servicios. Así pues, al hablar de comunicación entre objetos, podemos esquematizar una comunicación a través de puntos de interfaz que definen el intercambio de datos entre objetos y el intercambio de servicios entre grupos de objetos.

Conservando el estándar de sistema abierto, la adopción de los objetos como medios para la construcción de sistemas informáticos permiten, al poder residir en aplicaciones e inclusive en maquinas distintas, cooperar de la misma forma que en un esquema vertical entre modulos de una misma maquina, para ofrecer un servicio distribuido.

Algo que es digno de mencionar es que, Java permite que desarrollos en lenguaje C++ puedan implementarse como librerías nativas en Java, puesto que todas sus librerías de base están desarrolladas en C++. Con esto JMF puede implementar esquemas de compresión y codificación desarrollados en C++, a través del uso de sus managers como es el caso del plugin mcmager, de esta forma JMF como tal, sirve además, como una alternativa de soporte para el diseño y desarrollo de codificadores de audio y video.

Hasta el día de hoy, se considera que Java es, sino la mejor herramienta para desarrollar aplicaciones para Internet, sí la más amigable; a su vez, JMF proporciona una arquitectura fácil de entender e implementar.

Hasta el momento contamos con las bases suficientes para poder entender la arquitectura JMF y algunos nuevo conceptos que irán surgiendo para estudiar posibles desarrollos de aplicaciones Multimedia para Internet.

Por lo pronto solo nos falta mencionar que conceptos como “ Modelo de Eventos”, “Modelo de Datos”, y otros mas que aparecerán en la segunda parte, serían por ahora demasiado obscuros de abordar a estas alturas del presente reporte final; por ello mencionaremos su definición cuando así se requiera.

Bibliografía

http://www.altavista.com http://w~w2.netexplora.com/Cliente Servidor/index.html http://www.map.es/csi/silice/Global~html http://www4.uji.es/-alOl9803/Tcpip.htm http://webserver.pue.udlap.mx/-electro/REDES/Atm&uc/tsldO20.htm http://~w.disc.ua.es/asignaturas/rc/trabajos/ip/indice.html http://www.freesofi.org/CE/RFC/1889/index.htm http://www.gta.ufrj.br/-gardel/redes/rede.htm http://www.mot.com/MIMS/ISG/mnd/papers/voice - technologies for-ip-and-fiame-re1 ay-networks. html http://atenea.lasalle.edu.co/-crojasm/oot 1 O 1. html http://programacion.net/javd http://www.java.sun.com/nav/whatis http://ww.java.sun.com/products/java-medidjmf

-

Aprenda Java como si estuviera en primero Javier Garcia de Jalón, José Ignacio Rodriguez, Iiiigo Mingo, otros. Escuela Superior de Ingenieros Industriales Universidad de Navarra, San Sebastian Marzo 1999

Aprenda Servlets de Java como si estuviera en segundo Javier Garcia de Jalón, José Ignacio Rodriguez, Aitor Imaz. Escuela Superior de Ingenieros Industriales Universidad de Navarra, San Sebastian Abril 1999

Teach Yourself JAVA in 2 1 Days Professional Reference Edition Laura Lemay, Charles L. Perkinson, Michael Morrison Sams.net 1996

JAVA NETWORKING AND AWT API SUPERBIBLE Nataraj Nagaratnam, Brian Maso, Arvind Srinivasan Waite Group Press 1996

Learning Java Patrick Niemeyer, Jonathan Knudsen O’REILLY May 2000: First Edition

Java Media Framework A P I GUIDE JMF 2.0 FCS Sun Microsystems, Inc. and IBM Corporation November 19, 1999

48

Indice de figuras

Figura 1 . Red Conmutada 3 Figura 2. Arquitectura Cliente/Servidor 6 Figura 3. Módulos de una misma máquina 8 Figura 4. Formato del mensaje TCP 9 Figura S. Estructura de un datagrama IP 10 Figura 6. Formato de la Cabecera del IPv6 13 Figura 7. Fomlato del UDP 15 Figura 8. Formato RTP 17 Figura 9. Protocolos utilizados en VoIP 19 Figura 10. Red VoIP 20 Figura 1 l. Modelo referencia 41 Figura 12. Formatos de Video 43 Figura 13. Formatos de Audio 43 Figura 14. Arquitectura JMF 44

-

Indice Alfabético

A AfC5.1 I¿AACCION, 24 Alcance dinimica, 26 AIX; ?2 Alto descnqxfio, 25 Aplicaciones de los Servlets. -36 Aplicaciones de RTP y RTCP, 20 Applets. 28 Appletviewr. 28 ARPA. 8 Arquitectura Cliente/Servidor. 5

B Bibliogratinl 49

C CGI's, 35 Ciclo de vida de un applet, 30 Ciclode de vida del Servlet (explicación del

Circuitos vutudes; 4 clase .-l. Lease clase B, 13 clase C, 13 clase D, I3 clase E, I3 CODE, 32 CODEBASE, 32 Código del Servlet, 39 COMUNICACION ENTRE OBJETOS, 24 Conclusiones, 48 Conmutación de Circuitos, 3 Conmutación de Mensajes, 3 Comnutacion de Paquetes, 3 Content Type, 42 Crcrinliento o Escalnbilidad, 5

código), 4 1

D Data Sidi . 44 Datagramas, 4 Digital, 24 Digital Alpha Server, 25 Dinámico, 26 Direccionamiento IPv6, 14 Distribuido, 25

E Ejecución multihilo, 33 Encapsulado, 26 ENCAPSULAMIENTO, 24 ESPECIALIZACION, 24 Etiqueta APPLET, 31

F FORMULARIO, 37 FTP, 9

H H.323. 20 HEIGHT, 32 !rerencia. 26 IITTP. 9 NTTP GET. 38 IlTTP POST. 38

I ETF, 17 Mice de figuras. 50 Itrteroperabilidntl~ 5 Interpretado, 25 Introducción; 3 rp, I O IPv6: I3 IRIX, 24 ISO, 5 ITU-T, 16

J Java, 25 java. awt, 27 java.io, 26 java.Img, 26 juva.net, 26 java. util, 27 JMF : Java Media Framework API Guide, 42

M Manejo de memoria, 27 Mecanismos de Envio de Información, 3 media stream, 42,43 Medios que degxnden del tiempo, 42 Metodos del applet, 30 Modelo de Referencia, 43 Multithread, 26. I ease

N NAME, 32 NIC, 13

O OBJETO, 23 Orientado a objetos, 25 OSI, 9

P Paso de parámetros, 32 Polimortismo, 26 POLIMORFISMO, 24 Portabilitiari, 5 Portátil, 25 Presentacion, 1 Protocolos, 8

I

50

Pull: 43 Push. 43

R Recolección de basura, 27 Redes Conmutadas, 3 Redes de Difusión, 3 rmlderer, 44 REUSABILIDAD:, 24 Robusto, 25 RTCP, 19 RTP, 16

S Seguro, 25 Servlets, 35 SGI, 25 Simple, 25 Sistemas abiertos, 4 Socket, 7 Solaris, 24 Streanmring Media, 42

T TCP. 9

TCPIIP, 8 Tecnología de objetos, 23 tecnologías de la información, 1 TELNET, 9 Transmisión de voz. 2 1

U UDP, 15 UNIX, 24

V VALUE, 32 void destroy(), 30 void init(), 30 void paint(Graphm), 31 void print(Graphics), 31 void repaint()> 30 void start(), 30 void stop(), 30 void update(Graphics), 30 Vow: Voice on IP: 20

w WIDTH, 32 Windows NT, 24

1

I ransporte de voz 2 2 5 9 3 0

sobre protocolo

TCPIIPysu lmplementaclon

con JMF.

Marco U. Proyecto

López D. Terminal I 1

.. I I

lmplementación

... 111

Transporte de Voz sobre Protocolo TCP/IP y su lmplementación con JMF.

Implementación

Marco Ulises López Díaz

Universidad Autónoma Metropolitana Unidad Iztapalapa

División de Ciencias Básicas e Ingeniería Departamento de Ingeniería Eléctrica

Licenciatura en Ingeniería Electrónica Area de concentración: Comunicaciones

Proyecto Terminal I1

México, D.F. Mayo de 2001

Prefacio

El presente documento concluye la segunda parte del trabajo de investigación “Transporte de voz sobre el conjunto de protocolos TCP/IP utilizando el lenguaje Java y su interface Java Media Framework”.

Este documento llamado “Implementación”, refleja el trabajo realizado al implementar la arquitectura descrita en esa interface, así como de las características y recomendaciones que debe uno seguir con el entorno de programación utilizado: JBuilder version 2.0 1 de Borland.

Se propuso este modelo de arquitectura para el tratado de medios, considerando y tomando las ventajas ya conocidas del lenguaje de desarrollo, agregando a estas que la arquitectura propuesta por J M F , en vista de ello es totalmente didáctica para el claro entendimiento del tratado de medios que dependen del tiempo.

El entorno de desarrollo, Jbuilder, se utilizó debido a sus características de ayuda en línea y sobre todo por la característica de mostrar referencias rápidas, de los métodos o variables aplicables a cada sentencia.

Organización y Cobertura

A fin de lograr reunir la mayor experiencia acumulada durante el desarrollo de este trabajo, primeramente se da una descripción del problema a tratar, a continuación se muestra el código propuesto y se explican las líneas de código más importantes, y por ultimo, se agregan las conclusiones pertinentes para cada tema previamente tratado.

Durante esta parte del proyecto, irán surgiendo nuevos conceptos, que por su grado de complejidad no heron tratados en el apartado anterior llamado Bases Teóricas, debido a que es mejor tratarlos en el momento de su utilización.

La implementación del transporte de voz, sienta las bases para el entendimiento del transporte de medios que requieren un tiempo de entrega específica y ciertas características de proceso y envío, deja pues un precedente para mejorar este trabajo y desarrollar nuevas implementaciones a futuro.

m

V

Anteproyecto

Utilizando el ambiente de desarrollo Jbuilder de Borland, se pretende mostrar de la manera mas clara, el uso de la interface J M F y su implementación para el tratamiento de la voz, para poder así, manipular, procesar, transmitir, recibir y presentarla desde un navegador de Internet (como Comunicator o Explorer).

Esta aplicación utiliza como interfaz gráfica un applet para su reproducción y toma ventaja de los servlets para el intercambio de información a través de la red.

En conclusión, el proyecto en conjunto, permitirá el desarrollo de una aplicación, para que un profesor mediante una presencia virtual, se comunique con sus alumnos (virtuales también para é1) enviando la voz a través de la Internet, inclusive, permitirá mantener un acervo de esas sesiones en formato. mp3 para un intercambio posterior.

Contenido

Prefacio iv

Organización y Cobertura iv

Anteproyecto v

Introducción 1

Modelo de eventos 1 Modelo de datos 1 Fomlato de Datos 3 Extensión 3 Controles Estandar 4

Presentación de Medios 5

Player 5 Estados del Reproductor 6 Métodos disponibles 7

Procesando los LMedios 15

Processor 15 Estados del Procesador 16 Métodos disponibles en cada estado del Procesador 17

Capturando medios 18

Trabajar en Tiempo Real 27 Arquitectura RTP 27 Transmitir con RTP 27 Session Manager 27 Recibir y Presentar con RTP 28

Conclusiones 29

Bibliografía 30

Indice de Figuras 31

Indice Alfabético 32

Introducción

Modelo de Eventos

JMF usa un mecanismo estructurado de reporte de eventos (ver Figura l), para mantener informados a los programas del actual estado del medio tratado y permite a estos programas basados en JMF responder y manejar condiciones de error, como pudiera ser tal vez al presentarse un error de no-disponibilidad de algún recurso de salida de datos como un par de bocinas.

Para cada tipo de objeto JMF que puede reservar un Media Events, JMF define una interface de atención correspondiente. Para recibir notificación cuando un MedioEvents es reservado, se implementa su apropiada interface de atención y se registra la clase que atiende, junto con el objeto que reserva el evento, llamando al metodo oddLisrener.

Los objetos RTPSessionManager (tratados mas adelante) también reservan eventos.

Modelo de Datos

Los Players de JMF usualmente usan un DataSource para manejar la transferencia del contenido del medio (ver Figura 2). Un DntaSource encapsula la ubicación del medio y el protocolo y software usado para entregar el medio. Una vez obtenido, la fbente no puede ser usada para entregar otro medio.

Un DatnSource es identificado por un MedinLocator o un URL (Universo1 Resource Locator) Un MedinLocator es similar a un URL y puede ser construido desde un URL , pero solo puede ser contruido solo si el coorrespondiente manejador de protocolo esta instalado en el sistema.

Un DataSozrrce maneja un conjunto de SourceStream objects. Una fbente de datos estándar usa un arreglo de bytes como unidad de transferencia. Un bufferdatasource usa un Buffer con su unidad de transferencia.

2

manages one or mre SourceStream

*& 4 PullDataSuurce

i

i 1 1 1 : .....I..I__..._.___ ~ PullBufferData43ul-ce

i !”..“.I ”... PushDataSuurcr

_._,- _-._____ PushEuffcrDatafc~urce

I

Figura 2. Modelo de Datos

Los datos de un medio cualquiera pueden ser obtenidos desde una variedad de fuentes, como un archivo local o ubicado en algún punto de la red, o bien para servicios de transmisión en vivo. Las fuentes de JMF pueden ser organizadas de acuerdo a como se inicia la transferencia de datos:

Pull Data-Source : el cliente inicia la transmisión y controla el flujo de datos desde el 1”ullDataSource.

Push Data-Sourqe : el servidor inicia la transferencia de datos y controla el flujo de datos desde un PushDataSource. PushDataSource incluye servicios para broadcast, multicast y video sobre demanda (VOD). Para el servicio de Broadcast utiliza el protocolo RTP.

Asi pues, JMF define dos tipos datos para enviar (push): PushDataSource y PzuhRz~ferDataSozcrce, el cual usa un objeto Buffer como su unidad de transferencia. Existe también dentro de la arquitectura un par de DataSource especiales, Clonable y Mezclado (merging). Un DataSource clonable, puede ser usado para crear clones de cualquiera de los tipos de dato ya mencionados, PullDataSource o PushDataSource. Estos clones no necesariamente deben tener las mismas propiedades del DataSource clonado o el original DataSource. Por ejemplo un DataSource clonado creado para un dispositivo de captura, podría h c i o n a r como master de sus clones, y utilizar cada uno de los clones para obtener diversos formatos y de la misma entrada.

Un MergingDntaSource puede ser usado para combinar diversas tramas (SourceStream) de varios DataSource dentro de un sencillo DataSource. Esto permite que un conjunto de DataSource pueda ser manejado desde un solo punto de control, cuando se conecte, desconecte, inicie o se detenga se estará llamando a MergingDcrtaSource, las llamadas al método son propagadas a todos los DataSozrrces mezclados.

Formato de Datos

El formato exacto del medio (ver Figura 3) se representa mediante un objeto Fornmf . El formato por sí mismo no lleva parámetros específicos de codificación o información global de tiempo de presentación, solo describe el nombre del formato y el tipo de dato que el formato requiere.

Fulmar 1

1 P E G F o I - I I I ~ ~

H2 6 5Forlrlat

Figura 3. Formato de Datos

Extensión

Para los desarrolladores avanzados y los provedores de tecnología, J M F permite extender su hcionalidad de dos maneras:

0 Implementando sus propios componentes de procesamiento (plug-ins) que puedan ser intercambiados con los componentes estandar de proceso y,

Directamente implementando manejadores @Zoyers. processors, datasource)

4

Controles Estandar

JMF define interfhces de control estándar, mostradas en la Figura 4. Una de las más importantes en este estudio es el control de track'. Un TruckControl es un tipo de control de formato (FormarControl) que proporciona un mecanismo para controlar que proceso se realiza sobre un particular track. Con el método TruckControl, tu puedes especificar que tipo de conversión de formato se realiza sobre un individual track, y poder seleccionar los efectos o codificadores que serán usados en el proceso de los datos.

61rf f e rbr r t ro l

FarmatConttal

f

F r a n c P c s i t i o n i n g C m t r o l

F r a m e P m c e s s i n g i ~ n t t - ~ l

FI-ameRate6rrtrol

_...I Gaintbmtrol

H263Comtrul

i -

M o n i t o K u n t t u l

~~. " " ._ . ~ . . " Npeg.4udioiontrol

. . . . . . . .. . . . . . . P a c L e t 5 i : d o n t l ~ l

1 J

U u a l i t ~ < w n t m l

I I

Si lgnceSupprrss ion~ontt~ l

S t r e a m k r i t e t i u n t r u l l Figura 4. Controles

' Para entender mejor el concepto de Track, pensemos en una transmisión de televisión. en ella se usan dos señales. la de audio y la de video, entonces decimos que se utilizan dos tracks en la transmisión si esta fuera monoaural y tres si se usara un canal nlas de audio para ser estéreo.

~

Presentación de Medios

En JMF el proceso de presentación esta modelado por una interface de control (Controller). Controller define los estados básicos y los mecanismos de control para que un objeto controle, presente o capture los medios tratados en este trabajo. Esta interface define también las fases que un controlador sigue a traves de este proceso y proporciona un mecanismo para controlar las transiciones entre estas fases. Esto es, un número de operaciones deben ser realizadas antes de que los datos puedan ser presentados o puedan ser consumidos.

Un Controller reserva una variedad de controles especificos (MediaEvents) para proporcionar notificación de los cambios y su estado. Para recibir los eventos desde un Controller, como un player, se debe implementar la interface (70rltrollerl,istet~er.

Esta arquitectura define dos tipos básico de Controller: Players y Processors. Un player o processor esta construido para un particular DataSolrrce y normalmente no es usado para presentar otro tipo de dato.

Player

Un reproductor o Player, procesa un flujo de datos de entrada y lo envia con el preciso tiempo de entrega. Un DataSource es usado para entregar la entrada de flujo de datos al Player. A donde será enviado ese flujo de datos, depende del tipo de dato a ser presentado.

La Figura 5 presenta el modelo a bloques del funcionamiento de un Player

Cabe aclarar que un Player no proporciona ningún control sobre el proceso que se realiza o como se entregan los datos.

Figura 5. Modelo de reproducción

6

~~ ____~ ~~~ ~

Estados del Reproductor

Un Player puede estar en uno de seis estados. L a interface Clock, define dos tipos de estados primarios: Stopped y Started (Detenido e Iniciado).

Un Player reserva TransitionEvents al moverse de un estado a otro. La interfaces C'onrrollevListenev proporciona una manera para que el programa determine el estado del reproductor y este responda de manera apropiada. Por ejemplo, cuando el programa llama a un método asincrono sobre un Pkyev o Processor, necesita atender el apropiado evento para determinar cuando la operación se completo.

Métodos disponibles

Para prevenir condiciones de bloqueo, no todos los métodos pueden ser llamados sobre cada estado del reproductor. La Figura 7 muestra las restricciones impuestas por la arquitectura.

. . . . . . . . .- . . . . . . . . . . . . . . . . . . . . . ._ . . . . . . . . . . . . . . _I . . . . . . . . . . . . . . .......

syncstart , PTotPrefetchsdError PJctPrefetchedError legal ClocEtartedErrc,r

Figura 7. Restricciones de los estados del reproductor

8

Veamos un Ejemplo:

// PlayerApplet.Java

import java.applet.*; import java.awt.*; import java.net.*; import javax.media,*;

public class PlayerAppletl extends Applet implements ControllerListener {

Player player = null; String mediafile; Font TmRn = new Font("TimesRoman",Font.BOLD,36); Font Arl = new Font("Arial",Font.lTALIC, 18);

// Redefine el método Paint para mostrar el nombre del archivo que se ejecuta

public void paint(Graphics g)(

g.setFont(TmRn); g.setColor(Co1or.black); g.drawString("Escucha y Siente !!!",5,50); g.setColor(Co1or.darkGray); g.drawString("Escucha y Siente ! ! !",7,40); g.setColor(Color.gray); g.drawString("Escucha y Siente ! !!",9,30); g.setFont(Ar1); g.setColor(Color.black); g.drawString("Reading file:",5,75); g.setColor(Co1or.blue); g.drawString(this.mediafíle,5,95); 1

//AI llamar la página HTML, esta carga la clase y lo primero que se ejecuta de la clase es el metodo init();

public void init() { setLayout(new BorderLayoutO);

// 1. obtiene parametro FILE desde el HTML.

String mediaFile = getParameter("F1LE"); System.out.println("getParameter ready!"); System.out.printh(mediaFi1e);

//para usarla como local en paint, se crea una referencia a la variable de clase "mediafile" a //traves de "this"

thismediafile = mediaFile;

/I 2. Crea un URL desde el parametro FILE

URL mediaURL = new URL@etDocumentBase(), mediaFile); System.out.println("URL ready");

I/ 3. Crea un player con el objeto URL player = Manager.createPlayer(mediaURL); System.out.println("player ready");

11 4. Agraga la clase PlayerApplet como un Controlador. player.addControllerListener(this);

1 catch (Exception e) {

1 System.err.println("Got exception "+e);

f

115. Inicia la reproducción

public void starto {

playerstarto; System.out.println("Start ejecuted!"); 1

c

- . c . . .

// Al cerrar el navegador, se detiene la ejecución, pero se podría crear LUI boton que llame a este //método y detenerla en el momento que se desea l i '

I "

public void stop() { , ,

playerstop(); player.deallocate0; System.out.println("Stop ejecuted");

1

//Por default, la JVM destruye el applet, al cerrarse el navegador, liberando asi recursos del //sistema. También podría llamarse desde algún metodo en particular.

public void destroy0 { player.close0; System.out.println("destroy ejecuted");

1

//este método sincroniza la presentación de los componentes visuales y de control, para ser //mostrados cuando el estado del reporductor asi lo determine.

public synchronized void controllerUpdate(Control1erEvent event) { if (event instanceof RealizeCompleteEvent) {

Component comp; if ((comp = player.getVisualComponent0) != null)

add ("Center", comp); System.out.println("componente 'Center"');

10

if ((comp = player.getControlPanelComponent()) != null) add ("South", comp); System.out.println("componente 'South'");

validateo; 1

1 1

Como vemos con este ejemplo sumamente sencillo se nos muestran las caracteristicas y funcionalidad de tal arquitectura, y sobre todo lo amigable que resulta programar este código. Hablemos ahora de las características de configuración de nuestro entorno de desarrollo: Jbuilder.

Para poder realizar con gran éxito todos estos ejemplos, será necesario, primero determinar el nombre del proyecto que se está realizando, en particular se asignaron a cada uno de los ejemplos un nombre en particular, así se lleva a cabo m á s fácilmente su localización y depuración.

Primeramente, en el menu File de la barra de menus, seleccione New

Seleccione en la ventana siguiente, el icono Applet y presione OK

2 2 5 9 3 0

New 1 Panels 1 Menus 1 Dialogs 1 Data Modules 1 BeansExpress 1 Other 1

1 JavaBean Application m Project Frame Dialog

Se puede en este punto seleccionar el icono Class y realizar lo pasos siguientes pero, para nunca olvidar escribir los metodos Starto, Stop0 y destroy() del applet se recomienda seguir el procedimiento que hemos ya descrito.

ts\PlayerAppletlPlayerApplet.jpr

Title: Reproductor de Archivos

: Author:

: Companr fl

i Description: Deproduce archivos, con f o r m a t o i !

I . .. . . . . . ”. . _. . . . . .. .. ;r’ . . . . . . . . . . . . . . . . . . . . . .

Es importante tener en cuenta que nuestro código no se encuentra aún dentro de algún package (paquete), así que solo escribimos el nombre la carpeta para tener un almacenamiento de los archivos mas ordenado, sin embargo esta podría ser usada como un package. En este punto podemos dar una breve descripción de lo que se trata nuestro ejemplo. La ruta completa usada para t a l archivo es: C:VBUILDER2hyprojectsWlayerAppletWlayerApplet.jpr

A continuación escribimos el nombre exacto de la clase, este necesariamente tiene que coincidir con el nombre del archivo más la extensión “.java”. Dejemos el campo package en blanco.

Presionamos el boton Finish y nuestro entorno presentará cuatro archivos

En un archivo HTML (en cualquiera de ellos), necesitamos escribir el código que llamará a nuestra clase y la ejecutara, es importante que el archivo a reproducir se encuentre en la carpeta donde se encuentra la clase, esto es, por ejemplo en: C:VBUILDER2bnyprojectsWlayerApplet\.

Aunque el archivo a reproducir puede encontrare en cualquier sitio, es necesario para ficilitar el aprendizaje de este ejemplo en particular.

El código HTML necesario para la reproducción del archivo se agrega ficilmente desde el entorno de desarrollo, utilizando las pestañas que se encuentran en la parte inferior de la ventana, con la pestaña “Source”, puede verse el codigo HTML y con “View”, una vista rápida previa de cómo aparecería en un entorno de navegación, como Internet Explorer ó Netscape.

c HR> < S T R @ N G ~ V c r s i o n . . . j -< /STRO€?G><BR>

€ / FODJT> CAPPLET

CODEBASE = ". '' CODE = "FlayerApplet. class" NAME = "TestApplet LTIDTH = 350 HEIGHT = 125 HSPACE = U V 5 P d C E = O ALIGN = middle

> <PARAM NAIfE = F I L E VALUE ="vox 1 </RPPLET:> CO BODY> '</HTML>

mp3 ">

- .._.. __ . ._... ... : 30. t : Modified

El código HTML completo para la reproducción es el siguiente:

<HTML> <HEAD> <META €"P-EQUIV="Content-Type" CONTENT="text/html; charset=iso-S859-1"> <TITLE>Jbuilder Project PlayerApplet.jpr</TILE> </HEAD> <BODY> <Hl>Project Notes</Hl> <HR> <FONT SIZE=+l> <STRONG>Project: (/STRONG>Player Applet<BR> <STRONG>Author: </STRONG>Marco Lopez<BR> <STRONG>Description: </STRONG><BR> Player para archivos .wav y .mp3 <HR> <STRONG>Version.. . j</STRONG><BR> </FONT> <APPLET CODEBASE = "." CODE = "PlayerApplet.class" NAME = "TestApplet" WIDTH = 350 HEIGHT = 125 HSPACE = O VSPACE = O ALIGN = middle

> <PARAM NAME = FILE VALUE ="voxl.mp3"> </APPLET>

I

14

Ahora bien, ya tenemos el código de nuestra clase y el código que llamara a esta, en este punt0 podríamos compilar el código, sin embargo se recomienda echar un vistazo a las propiedades del proyecto para determinar donde serán compiladas nuestras clases, que no necesariamente estarán dollde indicamos que están los archivos fuentes, para esto usemos dos menús, el primero ‘‘T~ols” , selecciones “Default Project Properties” y en la pestaña “path” asegurece que la ruta de 10s archivos fuente (source) y de salida (output) concuerden con el propuesto, sin0 , cámbielos.

Del menu “Run” seleccione “Parameters” y en la pestaña “path”, realice los mismo cambios si fuese necesario.

Salvemos todo desde el menu “File”, y en el menu “Run” o presionando la tecla F9 ejecutaremos nuestro applet y podremos verlo desde al visor de java (AppletViewer).

El Applet Viewer se verá como:

Applet started. 1

En el shell de DOS que aparece como consola de Java, podemos ir monitoreando la carga de nuestro applet y veremos, si existe, alguna excepción o error al reproducir este archivo.

Hasta aquí, ahora ya podemos reproducir un archivo de audio mediante una applicacion sencilla como lo fbe el Player Applet, ahora necesitamos de las herramientas vistas hasta ahora y para entender el fbncionamiento de otro Controller llamado Processor. Con el cual podremos manipular direcatmente el flujo de datos y determinar una salida especifica como una direccion IP, un archivo de datos o de igual manera, enviarlo, a través de un player, a un dispositivo de reproducción.

15

Procesando los Medios

Un procesador (Proces.ror) puede ser usado para presentar cualquier tipo de medio. Un procesador esta pensado para proporcionar el control total sobre el procesamiento realizado a un flujo de datos (ver Figura 8). Un Processor soporta todos los controles de presentación que un Plqzr.

Figura 8. Modelo del Procesador

Processor

Un Processor es un reproductor que toma un DataSowce como entrada, realiza algún procesamiento definido por el usuario sobre el medio y entrega el medio procesado. Un procesador puede enviar los datos de salida a hacia un dispositivo de presentación o un DafaSource. Si lo datos son enviados a un DataSozme, este puede ser usado como entrada de otro porcesador o un reproductor o como la entrada de un DntuSink.

Mientras que el procesamiento reaiizado por un Player esta predefinido por el proveedor de esta arquitectura, un Processor permite a los desarrolladores de aplicaciones, definir el tipo de procesamiento que será aplicado a un medio especifico. Esto permite desarrollar aplicaciones de efectos, mezclado, y/o presentación en tiempo real.

EL procesamiento del medio, por sus características, esta dividido en vanas fsses (ver Figura 9)

0 Demultiplexado: extraer de un DataSorce, los track contenidos. Pre-Procesamiento: aplicar algoritmos de efectos a los tracks extraídos

0 Transcodificacion: Permite convertir cada track a otro formato. Post-Processing: aplicar algoritmos de efectos a los tracks codificados. Multiplexado: intercalar vanos tracks codificados para obtener un sola salida Enviado: presenta los medios al usuario.

16

"""-

GI L - - I I_ - I_ - Prooessor

Figura 9. Fases del Procesador

Cada &se se realiza con su propio componente, Demultimplexer,Eflect, Codec, Multiplexer, Renderer.

Estados del Procesador

Un procesador tine dos estados adicionales a los ya vistos para el Player: Configurando (Configuring) y Configurado (Configured), los cuales ocurren ants de que el procesador entre en el estado Realice (ver Figura 10).

Figura 1 O. Estados del procesador

Mientras que un Processor esta en el estado configured, el metodo get7rmkControl puede ser llamado para obtener objetos de control (TrackControl) para cada uno de los tracks.

17

~~ ~ ~ ~~ ~~ -

Métodos disponibles en cada estado del Procesador

De igual manera que un p/cg,er. no todos los métodos pueden ser llamados sobre cada estado del procesador. La Figura 1 1 muestra las restricciones impuestas por la arquitectura JMF.

getV1sualC;rnponent NotReallzedError

.~ ~.

seth1edlaT;mc IJotReallzedError NotResllzedError NotReallzedError le@

setRate NotEalizsdError I.Jo@rallzedError %tJ?eailzedErmr legal

setStlpTlrt1i- I.3utRahzedError N u t r a h z l J E r r o r NotReallzeclError leqai

NotRcallzadError NotReal~zedError NotRe-illzedErmr 1 F.qa 1 : se'TlmeRase ~~ ~~ ..~. ~ . .~

. . . . . . . . . . . . . . . . . . . . . . . ... . . . . . . . . . . . . . . ..

syncstart PIotPrefetchedError FTotPrefetchedError PlotPrefetchedError FTotPrefetchtdError .... .... ........ - ................ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . "" . . . . . . . . .

Figura 11. Métodos disponibles para los estados del procesador.

Hasta aquí, se puede entender en sus aspectos básicos como es el hncionamiento de nuestro servlet para la captura de voz. Este programa permite reconocer un dspositivo de captura como un micrófono y tomar el flujo de datos de 61 mismo, codificarlo y salvarlo en algún formato propio de la arquitectura, en particular se usó el formato. mp3 para este ejemplo. *

18

Capturando medios

En esta ocasión, veamos primero el codigo HTML y análicemos paso a paso como funciona.

<HTML> <HEAD> <META E.FITP-EQUN="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <TITLE>Voice Session Servlet</TITLE> </HEAD> <BODY> <H 1 >Project Notes</H 1 > <HR> <FONT SIZE=+l> <STRONG>Project: </STRONG>ServletVoiceProcessor<BR> <STRONG>Author: </STRONG>Marco Lopez<BR> <STRONG>Company: </STRONG>lis<BR> <STRONG>Description: </STRONG><BR> Captura, procesa y monitorea sesion de voz <br> <br> <STRONG>Servlet de sesión de voz.. .</STRONG> <BR> </FONT> <UL> <!-- Comentarios -->

Las líneas anteriores solo representan el encabezado que Jbuilder coloca y algunos comentarios, la siguiente línea es una de las más importantes:

<FORM ACTION="http://l27.0.0.1:8080/servlet/ServletVoiceProcessor" METHOD="POST">

Esta línea llama a la clase ServletVoiceProcessor en la direccion IP especificada, para este ejemplo, usamos la dirección del sistema local para poder ejecutarla con el SertvletRuner de Java y evitamos configurar un servidor Web para ejecutar este ejemplo.

Para un ejemplo más real, el servlet debe estar colocado en la carpeta "servlet" de algún servidor de Web, como Apache o Internet Information Server (11s).

Para este ejemplo, no es posible ejecutarlo desde un servidor, ya que este debe contar previamente con los dispositivos de captura, y el usuario con los atributos para poder escribir y utilizarlo.

<br> <font size=+l>Ruta:<INPUT TWE="text" NAME="ruta" VALUE=file://c:/voxsession/player/ SIZE=40>

Las etiquetas INPUT permiten entregar al servlet los parametros necesarios, como el path para guardar el archivo y el nombre de este.

Las opciones de monitor, son bloques propuestos para la supervisión en línea de la calidad de la voz guardada. Aim no están implementados en este ejemplo.

Una vez que se presiona el boton Submit, se establece la conexión ó enlace con el servlet y el método init() se ejecuta por primera y única vez, permitiéndo que el método dopos(), pueda ser llamado con nuevos parámetros.

<INPUT TYPE="SUBMIT" NAME="ENVIAR* VALUE="Iniciar"> <INPUT TYPE="RESET" NAME="LIMPIARt VALUE="Limpiar">

</BODY> </HTML>

</FORM>

/I Serv1etVoiceProcessor.java // Este servlet, Captura un flujo de datos desde un micrófono, codifica el flujo capturado con un codificador. mpeg para audio y lo guarda en un archivo con el mismo formato (.nlp3).

import javax.servlet.*; import javax.servlet.http.*; import java.io.*; import java.util.*; import javax.media.*; import javax.media.control.StreamWriterContro1; import java.util.Vector; import javax.media.format.AudioFormat; import javax.media.protocol.*; import java.lang.Boo1ean;

import javax.media.control.TrackContro1; import javax.media.format.*;

public class ServletVoiceProcessor extends HttpServlet {

//Initialize global variables private String ruta=null;

private String archivo=null ;

20

private String path = null; private String monitorlocal = null; private String monitortx = null; private boolean monitorlocalactivo = false; private boolean monitorTxactivo = false; private String detener = null; private String destroy = null;

CaptureDevicelnfo devicein = null; Processor proc = null;

* StateHelper shelper = null;

Datasource DataSourceMaster; Datasource DataSourceClone; Datasource DSCloneLocalMonitor; Datasource DSCloneTxMonitor; DataSink filewriter;

HttpServletResponse response;

//Se incia una sola vez y espera peticiones, //captura el dispositivo de voz(microfono) //y espera para grabar en el archivo, enviarlo a dispositivo de sonido o //a la red.

public void init(Serv1etConfig config) throws ServletException { super.init(config);

System.out.println("Iniciando ServletVoiceProcessor.. .");

} //end of Init

//Process the HTTP Post request

public void doPost(HttpServ1etRequest request, HttpServletResponse response) throws ServletException, IOException

f detener = request.getParameter("detener"); destroy = request.getParameter("destroy"); if ( detener == null & destroy = null)

{ ruta = request.getParameter("ruta"); archivo = request.getParameter("archivo"); String path = ruta+archivo; thkpath = path; monitorlocal = request.getParameter("monitorloca1"); . monitortx = request.getParameter("monitortx");

// llamando al procesador principal de captura de voz Systenl.out.println("Starting processor of capture. .."); thkresponse =response; processor(archivo);

21

if ( monitorlocal != null ) I I

System.out.println("preparing local monitor..."); monitorlocalactivo = true; monitorLocalProcessor(monitorloca1activo); 1

if ( this.monitortx != null ) I I

System.out.printIn("preparing Tx monitor..."); monitorTxactivo = true; monitorTxProcessor(n1onitorTxactivo); 1

t else {

if ( destroy != null ) I stop 0 ; servletdestroyedHTML(resp0nse); System.out.println("Servlet destroyed"); System.out.print!n("By ...'I);

2 2 5 9 3 0

System.exit(-I);

System.out.println("Trying to stop..."); stop 0 ; serv!etstopedHTML(response);

3 1

//PROCESADOR PEUNCIPAL DE CAPTURA DE VOZ

public void processor(String archivo) f Vector deviceList = CaptureDeviceManager.getDeviceList(new

AudioFormat(AudioFormat .LINEAR44 100,16,1));

if (deviceList.size0 > O) c

System.out.print!n("Trying Capture device..."); devicein = (CaptureDeviceInfo)deviceList.firstElement(); System.out.println("get device ready!");

3 else

N si no puede encontrar un dispositivo que entregue audio a, // 44 1 O O H z , 16 bit, mono. c System.out.println("get device NOT ready!"); System.exit(-1);

1

try c System.out.println("Trying processor..."); proc = Manager.createProcessor( devicein.getLocator0 ); System.out.println("processor ready!");

shelper = new StateHelper(proc);

22

System.out.println("waiting for processor states. ..'I); } catch (IOException e) {

System.exit(-1);

System.exit(-I); 1

System.out.println(e);

} catch (NoProcessorException e) {

// Configurando el processor if (!shelper.configure( 10000))

System.out.println("Time over..."); System.exit(-1); 1

// Fija el tipo de contenido (Content Type) de la salida y realiza // el procesador

proc.setContentDescriptor(new FileTypeDescriptor(Fi1eTypeDescriptor.h System.out.println("Trymg Content Descriptor Output");

System.out.println("Content Descriptor Output ready!");

// Obtiene el control de cada track TrackControl track[] = proc.getTrackControls(); boolean encodingPossible = false;

// Para cada tracks lo codifica con el formato determinado . . . for (int i = O; i < track.length; i++) {

try{

APEG-.

System.out.println("Try to encode..."); track[i].setFormat(new AudioFormat(AudioFormat.MPEG)); encodingPossible = true;

System.out.println("Encoded"); } catch (Exception e) {

// no puede convertir a ... track[i].setEnabled(false);

} } if (!encodingPossible) {

shelper.close(); System.out.println("Canot encode");

Systen~.exit(-I); 1

// Realizando el procesador if (!shelper.realize(lOOOO))

f System.out.println("Rea1ize state NOT ready!"); System.exit(-1);

1 I

AUDIO));

// Salida del processor en "Source" Systeln.out.println("Trying Data Source by processor"); DataSourceMaster = proc.getDataOutput(); this.DataSourceMaster = DataSourceMaster;

System.out.println("Data Source Master ready!");

System.out.println("Saving session in: "+path); // crea un MediaLocator utilizando el protocolo FILE y la ubicación

// del nombre de archivo que será generado

MediaLocator dest = new MediaLocator(path); System.out.println("Media locator ready!");

// crea la salida para el destino especifico (datasink) // en este caso es un archivo .wav // abre el archivo y se asegura que se escribio en el

DataSink filewriter = null; try

System.out.println("Trylng DataSink (File Writer)...");

thisfilewriter = filewriter; filewriter.open();

System.out.println("0pened File Writer & ready!");

filewriter = Manager.createDataSink(DataSourceMaster, dest);

} catch (NoDataSinkException e) { System.out.println("DataSink Error");

} catch (IOException e) { System.exit(-1);

System.out.println("Cannot open File"); System.exit(-1);

] catch (SecurityException e) { System.out.println("Security error") ;

System.exit(-1); 1

// llama a setStreamSizeLimit // para fijar el tamaño limite del archivo que se esta escribiendo. StreamWriterControl swc = (StreamWriterControl)

proc.getControl(t~avax.media.col~trol.StreamWriterControl");

//limite fijado en 20MB if (swc != null)

c swc.setStreamSizeLimit(20000000); System.out.println("Stream fixed in 20 MB");

f //detener? detenerHTML(this.response);

// comienza a procesar y escribir

System.out.println("Trying to write...");

System.out.println("writing.. .");

try {

fílewriter.start0;

1 catch (IOException e) {

I

24

System.exit(-1); 1

// Captura 1 O segundos

shelper.playToEndO~edia(300000); System.out.println("Capturing 300 seconds");

shelper.close0;

// Espera final de la trama desde el DataSink y cierra el archivo..

filewriter.close0; System.out.println('lrying to close new file :"+archivo );

System.out.println('Yile:" +archivo+ It closed" ); } //end of processor

public void detenerHTML(HttpServ1etResponse resp){ resp. setContentType( "texthtml 'I); Printwriter out = null; try t

out=resp.getWriterO;

System.out.println("Se ha producido una Excepcion"); }catch (IOException io) {

1

out.println("<HTML>"); out.println("<Head>");

out.println("<title>Detener captura?</title>"); out.println("</head>"); out.println("<body>");

out.println("<FORM ACTION=http://localhost:808O/servlet/ServletVoiceProcessor"); out.println(" METHOD=POST> "); out.println("<br>");

out.println("<p><b><Font size=+2>Sesión grabando en: </font></b>"+path+""); out.println("<br> 7 ; out.println("<br> "); out.println("<font size=+l>¿Detener Captura?<SIZE=lO > "); out.println(" <br> Y ; out.println("<br> Y ; out.println("<br> "); out.println(WNPUT TYPE=RADIO CHECKED NAME=detener VALUE=true

out.println("<INPUT TYF'E=RADIO NAME=destroy VALUE=true >Apagar Servlet

out.println(" </font>"); out.pnntln(" "1; out.println(" <br> "); out.println(WNPUT TYPE=SUBMIT NAME=ENVIAR VALUE=Detener>"); out.println("<INPUT TYF'E=RESET NAME=LIMPIAR VALUE=Limpiar> ");

>Detener Captura<br>");

<br>");

out.println("<br>"); out.println("</FORM>");

out.println("</body>"); out.println("</HTML>"); out.flusll();

8 , I

25

out.close(); I

public void servletstopedHTML(pServ1etResponse resp)( resp.setContentType("text/htlnlft); Printwriter out = null; try I

)catch (IOException io) {

1

out.println("<HTML>"); out.println("<Head>"); out.println("<title>Iniciar de nuevo?</title>"); out.println("<~lead>"); out.println("<body>");

out=resp.getWriter();

System.out.println("Se ha producido una Excepcion");

out.println("<FORM ACTION=http://localhost:SOSO/servlet/ServletVoiceProce~~o~"); out.println(" METHOD=POST> ");

out.println("<br> 7 ; out.println("<font size=+l>Captura Detenida "); out.println(" <br> ; out.println("<br>iIniciar de nuevo?<SIZE=lO > "); out.println("<br> "); out.println("<br> "); out.println("<font size=+l>Ruta:<INPUT TYPE=text NAME=ruta

VALUE=file://c:/voxsession/player/ SIZE=40>");

out.println("<br> "); out.println("<font size=+l>Guardar sesión en archivo:<lNPUT TYPEqext

NAME=archivo SIZE=10>"); out.println("<br>"); out.println("<br>"); out.println("<br>"); out.println(" <br>"); out.println("<INPUT

out.println("<INPUT

out.println("<br>"); out.println(" <br>"); out.println("<INPUT

Local<br>");

Tx<br>");

<br>");

TYPE=RADIO NAME=monitorlocal VALUE=true >Monitor

TYPE=RADIO NAME=monitortx VALUE=true >Monitor de

TYPE=RADIO NAMEdestroy VALUE-true >Apagar Servlet

out.println(" </font> "); out.println(" <br> "); out.println("<INPUT TYPE=SUBMIT NAME=ENVIAR VALUE=Enviar>"); out.println("<INPUT TYPE=RESET NAME=LIMPIAR VALUE=Limpiar>");

out.println("</body>"); out.println("</HTML>"); out.flush0; out.close();

out.println("</FORM>");

1

26

public void servletdestroyedHTML(HttpServ1etResponse resp){ resp.setContentType("'text/html"); Printwriter out = null; try{

out=resp.getWriterO;

System.out.printIn("Se ha producido una Excepcion"); }catch (IOException io) {

1

out.println("<HTML>"); out.println("<Head>"); out.println("<title>Servlet Apagado</title>"); out.println("</head>"); out.println("<body>"); out.println("<font size=+l>Servlet Apagado"); out.println(" <br> 'I);

out.println("<br>Levante el servidor ...< SIZE=lO > "); out.println("<br> ");

out.println("</body>"); out.println("</HTML>"); out.flush0; out.close();

out.println("</FORM>");

1

//Get Servlet information

public void stop() f

shelper.playToEndOfMedia( 1); System.out.println("end of media"); shelper.close0; fílewriter.close(); System.out.println("fi1e:" +archivo+ " closed" ); System.out.println("stop ejecuted");

1

public void destroy(Serv1etConfig config) throws ServletException { super.init(config);

System.out.println("destroy ejecuted");

public String getServletInfo0 { return "ServletProcessor Information";

I

27

Trabajar en Tiempo Real

Arquitectura RTP

JMF RTP fue diseñado para trabajar similamente con la captura, presentacion y procesamiento de la misma manera que lo hace JMF (ver Figura 12). Con la arquitectura JMF RTP se puede transmitir un flujo de datos capturado desde un archvio o desde una fuente como un micrófono o una cámara de video. Al igual que toda la arquitectura, podemos desarrollar nuestros propios codificadores y procesadores.

I Java Applications. Applets. Beans I 1 I JMF API

RTP APls

Figura 12. Arquitrectura J M F RTP

Transmitir con RTP

Para la transmisión de estos medios, es necesario tener un mecanismo que se encargue exclusivamente del control de la sesión en red, antes recibirlos (sesión cliente) y después de procesarlos (sesión servidor).

Session Manager

En JMF el Session Manager (ver Figura 13) es usado para coordinar todas aquellas sesiones que utilizan el protocolo RTP para el envío y recepción de estos medios. Este manejador de sesión, controla la cantidad de señales participantes y el flujo de datos que se envía.

. .. r -.

I

28

Recibir y Presentar con RTP

La Figura 14 muestra un esquema a bloques para la recepción de medios usando un manejador de sesión.

El manejador mantiene el estado de la sesión, visto como un participante l o c a l . Es decir, un manejador de sesión es una representación local de una entidad distribuida, toda la sesión RTP. El manejador también nlaneja el control de canales para envío y recepción de señalización mediante el protocolo RTCP (Real Time Control Protocol). Mantiene estadísticas sobre todos los paquetes que se envían o se reciben en la sesión, en su conjunto o por separado.

,

29

Conclusiones

El uso de un reproductor (player) para procesar y entregar el streaming en tiempo real esta limitado a las definiciones que proporciona el fabricante, en este caso Sun Microsystem, y solo lo usamos para fines didácticos, sin embargo, el uso de un Processor como reproductor, realiza un procesamiento bien definido por el desarollador sobre el medio y entrega el medio procesado con las Características requeridas. Un procesador puede no solo enviar los datos de salida a hacia un dispositivo de presentación, si no también, a un DatnSoztrce que puede ser usado como entrada de otro procesador o un reproductor o como la entrada de un manejador de sesión (SessionMmugcr) para reexpedirlo hacia un entorno de red. Esta implementación modular, permite desarrollar aplicaciones de efectos, mezclado, y/o presentación en tiempo real.

Hasta ahora, nuestra aplicación “Voice Session Servlet”, basada en Servlets, permite capturar y procesar el medio desde un solo dispositivo de captura y una sola estación de trabajo; s i n embargo, como las características propias de los servlets, sólo permiten realizar el reconocimiento de dispositivos de manera local’, se puede redefinir el diseño de captura de dispositivos y procesamiento en tiempo real, mediante una aplicación local, no servlets ni applets, es decir, una aplicación con su propio entomo que se instale en todas las máquinas servidores de voz, para que realice esta labor y reexpida el streaming a un servlet ubicado en nuestro web server, de tal forma que este sewlet roztter, solo sirva como encaminador del streaming hacia los clientes.

El Voice Session Servlet, puede codificar en todos los formatos que facilita la arquittectura y, cumpliendo con la escalabilidad de Java, permite que nuevos codificadores se implementen meidante plugins.

Para utilizar el Voice Session Servlet para la transmisión de streaming en vivo, es necesario tener un mecanismo que se encargue exclusivamente del control de la sesión en red (session mctnnger sewer) después de procesarlos y uno que se encarge de recibirlo (session manager client) para entregarlo al usuario. Como comentábamos, Session Mctnnger coordina todas las sesiones que utilizan el protocolo RTP ademas de la cantidad de señales participantes y el flujo de datos que se envía. Por el momento esta implementacion esta en una fase beta (de prueba y depuración) de desarrollo y por ello no se integró en este documento.

Finalmente este documento intenta acercar al usuario no experimentado en el tratamiento de medios que dependen del tiempo, a realizar aplicaciones sencillas que le permitan desarollar aplicaciones multimedia e integrarlas Gcilmente a sus aplicaciones para el Web. Además, le permite a desarolladores mas experimentados, utilizar JMF como una herramienta para implementar aplicaciones que evalúen nuevos esquemas de compresión, multiplexores, codificadores, generadores de efectos de audio y video y esquemas de transmisión en tiempo real de una manera sencilla y práctica.

- Esto no es del todo cierto, ya que se podria generar una aplicación que reconociera disposistivos en un entorno de red a traves de un sistema distribuido mediante RPC (Remote Procedure Call) en ese entorno. Pero este desarrollo se escapa del alcance de nuestro proyecto.

I

30

Bibliografía

Aprenda Java como si estuviera en primero Javier Garcia de Jalón, José Ignacio Rodriguez, Iñigo Mingo, otros. Escuela Superior de Ingenieros Industriales Universidad de Navarra, San Sebastián Marzo 1999

Aprenda Servlets de Java como si estuviera en segundo Javier Garcia de Jalón, José Ignacio Rodriguez, Aitor Imaz. Escuela Superior de Ingenieros Industriales Universidad de Navarra, San Sebastián Abril 1999

Teach Yourself JAVA in 21 Days Professional Reference Edition Laura Lemay, Charles L. Perkinson, Michael Morrison Sams.net 1996

JAVA NETWORKING AND AWT API SUPERBIBLE Nataraj Nagaratnam, Brian Maso, Arvind Srinivasan Waite Group Press 1996

Learning Java Patrick Niemeyer, Jonathan Knudsen O’REILLY May 2000: First Edition

Java Media Framework API GUIDE JMF 2.0 FCS Sun Microsystems, Inc. and IBM Corporation November 19, 1999

Referencias en Internet:

http://www.altavista.com http://www2.netexolora.com/Cliente servidor/index.html http://www.rnao.es/csi/silice/Global2.html htt~://www4.uii.es/-alO19803/Tcpip.htm httD://webserver.oue.udlap.n~x/-electro/REDES/Atm&uc/tsld02O.htm http://www.disc.ua.es/asi~aturas/rc/traba-ios/iD/indice.html http://www.freesoft.or.4CIE/RFC/l889/index.htm httD://www.gta.ufn.br/-nardel/redes/rede.htm http://www.mot.com/MIMS/ISG/mnd/papers/voice technologies for ip and frame relav net works.htm1 http://atenea.lasalle.edu.co/-crojasm/mtl01 .html httD://programacion.netJiava/ http://www.java.sun.com/nav/whatis http://www.iava.sun.com/products/iava-media/jmf

Indice de Figuras

Figura 1 Figura 2 Figura 3 Figura 4 Figura 5 Figura 6 Figura 7 Figura 8. Figura 9.

,

Modelo de Eventos 1 Modelo de datos 2 Formato de datos 3 Controles 4 Modelo del Reproductor 5 Estados del Reproductor 6 Restricciones en los estados del reproductor 7 Modelo del Procesador 15 Fases del Procesador 16

Fibra 10. Estados del Procesador 16 Figura I I . Métodos disponibles para los estados del Procesador 17 Figura 12. Arquitectura JMF RTP 27 Figura 13. Modelo de Transmisión utilizando un manejador de sesión 27 Figura 14. Modelo de Recepción utilizando un manejador de sesión 28

I

32

~~

Indice Alfabético

A addlistener, 1 Applet Viewer, 15 archivo H T M L , 13 Arquitectura RTP, 28 arreglo de bytes, 1

B Bibliografia. 30 buferdatasource, 1

C Capturando medios, 19 código H T M L , 13 condiciones de bloqueo, 7 control de track, 4 Controles Estandar, 4 Controller, 5 ControllerListener, 5 conversión de formato, 4

D DataSource, 1 DataSource clonable, 2 DataSource especiales, 2 DataSources mezclados., 3 Default Project Properhes, 15

E Ejemplo:, 8 entorno de desarrollo, 11 Enviado, 16 estado Configured, 17 estado Started, 7 Estados del Procesador. 17 Estados del Reproductor, 6 Extensión, 3

FomlatCorztrol, 4 formato mp3, 18 Formato de Datos. 3

getTmch-Contro. 17

Indice Alfabético, 32 Indice de Figuras, 31 interface de atención, 1 interface de control, 5 interfaces de control, 3

F

G

I

M mecanismos de control, 5 Media Events, 1 hiedialocator, 1 MergingDataSource, 2 metodo start, 7 Métodos disponibles, 7 Métodos disponibles en cada estado del

Procesador, 18 modelo a bloques Player, 5 Modelo de Datos, 1 Modelo de Eventos, 1 Multiplexado, 16

O objeto Format, 3 objetos RTPSessionManager, 1

P Parameters, 15 Player, 5 Players, 1 plug-ins, 3 Post-Processing, 16 prefetch, 7 Prefetched, 6 Prefetching, 6 ,7 Re-Procesamiento, 16 Presentación de Medios, 5 Processor, 16 Pull Data-Source, 2 PullDataSource, 2 Push Data-Source, 2 PushBufferDataSoure~ 2 PushDataSource, 2

R realize, 7 Realized, 6: 7 Realizing, 6 ,7 Recibir y Presentar con RTP, 29 Run, 15

S Session Manager, 28 shell de DOS; 15 SourceStream, 2 SourceStream objects. 1 ease Stoppcd: 6

T tipo de dato, 3 Tools. IS Trabajar en Tiempo Real, 28 track 4 TrachCoutrol. 4