1. UNIVERSIDAD REY JUAN CARLOS
Ingenier´ıa Inform´atica
Escuela Superior de Ciencias Experimentales y Tecnolog´ıa
Curso acad´emico 2006-2007
Proyecto Fin de Carrera
Plataforma para la gesti´on de emisoras de
radio sobre IP
Autor: Jos´e Ignacio P´erez Alcocer
joseignacio.perez@urjc.es
Tutor: Eugenio Jos´e Fern´andez Vicente
2. A mi familia y amigos,
por apoyarme y ayudarme
durante el desarrollo de
este proyecto.
Gracias.
3. Agradecimientos
No debo dejar pasar esta oportunidad sin agradecer a todas aquellas personas que en
mayor o menor medida han ayudado a que este proyecto se desarrollase:
Agradezco la colaboraci´on de los compa˜neros del Grupo de Audiovisuales y Redes
Multimedia (Jos´e Miguel Hern´andez, Juan Fabi´an Sim´on, Tom´as Cea, Jos´e Manuel
Serrano, Javier Ramos y Jos´e Antonio Almena), y, muy especialmente, a David
P´erez Redondo, ya que sin su aportaci´on y participaci´on este proyecto no hubiera
sido posible.
Estos dos a˜nos de colaboraci´on han resultado una grata experiencia, en la que
he adquirido una serie de conocimientos sumamente ´utiles que han servido para
complementar la formaci´on recibida durante la carrera de Ingenier´ıa Inform´atica.
A mi tutor, Eugenio Jos´e Fern´andez Vicente, por aceptar esta propuesta de Proyecto
Fin de Carrera y asumir la tutor´ıa.
Agradezco la ayuda prestada por todos mis compa˜neros durante los a˜nos que he
cursado la carrera de Ingenier´ıa Inform´atica. Mis m´as sinceros agradecimientos por
haber hecho mucho m´as llevaderos estos ´ultimos a˜nos de mi etapa en la Universidad
Rey Juan Carlos.
A todos mis amigos y familiares, por hacerme llegar, est´en donde est´en, su fe y
apoyo.
A todos mis profesores, por transmitirme sus conocimientos de la manera que mejor
saben.
A todos vosotros, gracias... Y hasta otra.
1
6. ´Indice de figuras
2.1. Arquitectura cliente-servidor. . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Workflow de la metodolog´ıa XP . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Ejemplo de petici´on y respuesta del protocolo HTTP. . . . . . . . . . . . . 15
2.4. Las p´aginas generadas cumplen con el est´andar XHTML. . . . . . . . . . . 16
2.5. Visualizaci´on de la p´agina sin aplicar y aplicando una hoja de estilos,
respectivamente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6. Comparativa entre el modelo de web cl´asico y un modelo de web AJAX . . 19
2.7. Esquema de un servidor de streming Icecast . . . . . . . . . . . . . . . . . 23
2.8. Esquema b´asico de clientes Ezstream y el servidor Icecast . . . . . . . . . . 25
2.9. Ejemplo de la disposici´on de la metainformaci´on ID3 en un fichero de audio 26
2.10. Mensajes SOAP del cliente y del servicio web. . . . . . . . . . . . . . . . . 27
3.1. Diagrama de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1. Estructura de la base de datos de la aplicaci´on. . . . . . . . . . . . . . . . 35
4.2. Fichero de configuraci´on de Ezstream para una emisora. . . . . . . . . . . 38
4.3. Definici´on del punto de montaje en el fichero de configuraci´on de Icecast. . 38
4.4. Snapshot de una playlist y fichero m3u asociado. . . . . . . . . . . . . . . . 39
4.5. Spnashot de la nueva playlist y el fichero m3u generado. . . . . . . . . . . 39
4.6. Porcentaje de cuota de disco ocupada. . . . . . . . . . . . . . . . . . . . . 41
4.7. Mensaje de petici´on SOAP del cliente y respuesta del servicio web. . . . . 42
4
7. Cap´ıtulo 1
Objetivos e introducci´on
1.1. Objetivos
El objetivo del presente proyecto es el desarrollo de una plataforma para la gesti´on de
emisoras de radio sobre IP, para su posterior aplicaci´on en el ´ambito docente: el pr´acticum
de la carreras impartidas en la Facultad de Ciencias de la Informaci´on que requieran del
medio radiof´onico.
Un segundo objetivo es el uso de esta plataforma como medio de distribuci´on de
contenidos multimedia por parte del Grupo de Audiovisuales y Redes Multimedia.
Esta aplicaci´on se presenta como una soluci´on a una serie de problemas de diversa
´ındole:
dificultad para la adquisici´on de una licencia de emisi´on de radio hertziana:
la necesidad de numerosos tr´amites burocr´aticos (las concesiones de licencia y
asignaciones del espectro de onda dependen del Ministerio de Ciencia y Tecnolog´ıa),
unido al elevado coste de las infraestructuras necesarias para la radiodifusi´on
tradicional, hacen que la alternativa de utilizar internet como medio de difusi´on
sea una soluci´on casi id´onea: amplia notablemente el hipot´etico n´umero de oyentes
(se estiman en torno a los mil dos cientos millones de usuarios de internet), y se
reduce el coste de las infraestructuras (que se limitan a un ´unico equipo inform´atico),
entre las ventajas m´as destacables.
inexistencia de un medio unificado para la entrega de los trabajos de los alumnos:
hasta la fecha, no existe un criterio para la entrega del material audiovisual creado
por el alumno; con esta plataforma se busca proveer un medio uniforme para que
el alumno pueda entregar sus trabajos.
el Grupo de Audiovisuales y Redes Multimedia busca una nueva herramienta para
la difusi´on de sus contenidos, y que mejor forma que desarrollar una aplicaci´on
propia, que se adapte a las necesidades que surjan (por ejemplo, soporte para
nuevos formatos de audio o video que ofrezcan mayores ratios de compresi´on o mayor
calidad a igual ratio de compresi´on, o servicios web que ofrezcan una determinada
funcionalidad).
5
8. CAP´ITULO 1. OBJETIVOS E INTRODUCCI ´ON 6
1.2. Introducci´on
La radio por Internet evoluciona a un ritmo vertiginoso, al que la sociedad de la
informaci´on aprende a adaptarse de forma sincr´onica.
Desde la aparici´on del Real Audio, el software que hizo posible la emisi´on en tiempo
real, otros muchos sistemas (como Windows Media Player o Real One Player) han
proliferado en un mercado emergente que impone unas nuevas reglas de juego.
La informaci´on difundida a trav´es de Internet es mucho m´as compleja de lo que jam´as
se hubiera imaginado. La informaci´on sonora a trav´es de la red aparece acompa˜nada de
otros elementos, escritos y visuales, y de un inmenso potencial interactivo que permite al
radioyente virtual navegar libremente y, seg´un las visiones m´as optimistas, derivar´a en la
configuraci´on de una radio a la carta (los populares podcast, verbigracia).
La radio por Internet presenta tantas novedades en el lenguaje, la forma y el contenido
que casi podr´ıamos hablar m´as que de la emergencia de un nuevo modelo o de una
tercera generaci´on de radio, del nacimiento de otro medio. Con las nuevas posibilidades
tecnol´ogicas, la informaci´on eleva a la m´axima expresi´on su funci´on de servicio p´ublico
ofreciendo contenidos utilitarios permanentemente actualizados, proporciona servicios
como las fonotecas, facilita la interactividad con el oyente mediante chats, foros o correos
electr´onicos y la recepci´on de im´agenes a trav´es de internet. La posibilidad de acceder
a sus contenidos a cualquier hora del d´ıa, desde cualquier lugar del mundo lo vuelve un
servicio popular para la poblaci´on emigrante en el extranjero.
Al margen de estos servicios, Internet amplia la oferta de la radio tradicional y permite
acceder simult´aneamente a otros documentos adicionales, como biograf´ıas de personajes
p´ublicos u otras noticias relacionadas. As´ı mismo rompe con la fugacidad del medio y de
la transmisi´on en tiempo real y ofrece al oyente la posibilidad de recuperar fragmentos
almacenados.
El desarrollo de este nuevo modelo se fundamenta en aquellas empresas que no
disponen de concesiones de emisoras hertzianas, ya que se rige por la legislaci´on de Internet
y apenas existen impedimentos para que cualquier iniciativa se lleve a cabo, tal y como
pone de manifiesto la creciente presencia de emisoras de radio en l´ınea: m´as de tres mil
en todo el mundo.
Existen diversas motivaciones que llevan a una emisora de radio a configurar un espacio
en la red: desde tener presencia institucional a ampliar su cobertura y, en consecuencia
su mercado. Por su parte, la emisi´on sonora a trav´es de la web puede ser en directo, en
diferido o mixta. Por lo general, son las grandes cadenas, como RNE, las que optan por
emitir en directo. La COPE ofrece adem´as cortes sonoros con lo m´as destacado del d´ıa.
Cadena SER se sit´ua a la vanguardia ya que archiva su informaci´on y permite al oyente
escuchara cuando lo desee (los denominados podcast). En las radios locales o regionales
predominan las emisiones en diferido.
Hoy en d´ıa, la combinaci´on de emisiones por ondas hertzianas con las realizadas desde
Internet representa la oferta ideal. El uso generalizado del ordenador como herramienta de
9. CAP´ITULO 1. OBJETIVOS E INTRODUCCI ´ON 7
trabajo, el fen´omeno imparable de la globalizaci´on y la creciente transnalizaci´on, as´ı como
las interminables posibilidades que brinda el mercado de la telefon´ıa m´ovil y los equipos
port´atiles, constituyen los cimientos de un nuevo entorno laboral y social que se sit´ua a
a˜nos luz de aquellas tardes en familia en torno al transistor.
En la era del marketing, la imagen de la cadena mejora con su presencia en la web y
refuerza la fidelizaci´on a la marca al ofrecer en una misma p´agina enlaces con otras radios
tem´aticas que pertenecen a la misma cadena, as´ı evita que el oyente pierda el v´ınculo con
la emisora y mejora su rentabilidad, garantizando la presencia de publicidad que es, en
definitiva, el sustento de Internet (y, generalizando, de todos los medios).
Las perspectivas en un futuro pr´oximo apuntan, como hemos se˜nalado, al nacimiento
de una radio a la carta, del mismo modo que ha ocurrido con la televisi´on y los peri´odicos
digitales, siempre y cuando haya contenidos por los que la audiencia est´e dispuesta a pagar.
La navegaci´on aporta un valor a˜nadido al oyente que puede buscar los contenidos que m´as
le interesen. En este sentido, la incorporaci´on de sistemas de b´usqueda de contenidos entre
el amplio abanico de emisoras on-line juega un papel crucial.
Por su parte, el profesional que desempe˜na su trabajo en la radio por Internet debe
reciclarse y formarse en una serie de materias que hasta hace poco eran ajenas a la
profesi´on period´ıstica. Entre estas habilidades destacan la creatividad y la capacidad de
para dise˜nar contenidos atractivos mediante la interactividad y los hiperenlaces.
Muchos expertos contemplan con escepticismo la ruptura de un medio fuertemente
arraigado en la historia y la vida cotidiana de una sociedad que viaja en coche, trabaja con
m´usica de fondo y prefiere las retransmisiones radiof´onicas a las retransmisiones contenidas
de los comentaristas deportivos de la televisi´on. Otros tantos muestran su entusiasmo ante
la que consideran ser´a el modelo predominante radiof´onico en un futuro, cuando ya no
haya necesidad de apelar al adjetivo digital. Sin embargo, hay al menos tres aspectos en
los que ambas visiones convergen: la magia de la radio, de hoy y siempre, radica en el
poder de la palabra, de los sonidos de ambiente, de la m´usica; en la inmediatez de su
informaci´on y, sobre todo, en el di´alogo directo y cercano con la audiencia. Cosas que la
tecnolog´ıa no puede cambiar, tan s´olo mejorar.
10. Cap´ıtulo 2
Tecnolog´ıas y heramientas empleadas
En esta secci´on se detallan las tecnolog´ıas y herramientas empleadas en este proyecto.
Destacar que esta aplicaci´on hace uso de gran parte de las tecnolog´ıas de ´ambito web
imperantes en el mercado actual (web services, PHP, AJAX, XHTML, y CSS, entre otras),
y una serie de herramientas espec´ıficas (Icecast, Ezstream), que componen el back-end de
la aplicaci´on. La gesti´on de emisoras se realizar´a v´ıa web (front-end), a trav´es de cualquier
navegador web.
El desarrollo de la plataforma se ha llevado a cabo en un entorno LAMP (un sistema
Linux, con el servidor web Apache, el sistema gestor de bases de datos MySQL y utilizando
como lenguaje de programaci´on PHP), usando en todos los casos software libre.
As´ı mismo, se describe la arquitectura y paradigmas de programaci´on empleados en
el sistema.
2.1. Orientaci´on general
La aplicaci´on implementa una arquitectura cliente-servidor, y hace uso de los
paradigmas de programaci´on estructurada y programaci´on orienta a objetos. El lenguaje
de programaci´on elegido, PHP, permite combinar en un mismo sistema sendos paradigmas
de programaci´on, si bien es cierto que hasta la aparici´on de la versi´on 5.0 de PHP
no se puede hablar de un modelo de objetos propiamente dicho (con la inclsui´on de
caracter´ısticas tales como herencia y polimorfismo).
2.1.1. La arquitectura cliente-servidor
Esta arquitectura consiste b´asicamente en que un programa, denominado cliente,
realiza peticiones a otro programa, el servidor, el cual proporcionar´a una respuesta.
La capacidad de proceso est´a repartida entre los clientes y los servidores, aunque son
m´as importantes las ventajas de tipo organizativo debidas a la centralizaci´on de la gesti´on
de la informaci´on y la separaci´on de responsabilidades, lo que facilita y clarifica el dise˜no
del sistema.
8
11. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 9
La separaci´on entre cliente y servidor es una separaci´on de tipo l´ogico, donde el
servidor no se ejecuta necesariamente sobre una sola m´aquina ni es necesariamente un
s´olo programa.
Una disposici´on muy com´un son los sistemas multicapa en los que el servidor
se descompone en diferentes programas que pueden ser ejecutados por diferentes
computadoras, aumentando as´ı el grado de distribuci´on del sistema.
La arquitectura cliente-servidor sustituye a la arquitectura monol´ıtica en la que no
hay distribuci´on, tanto a nivel f´ısico como a nivel l´ogico.
Las principales ventajas de la arquitectura cliente-servidor son las siguientes:
Centralizaci´on del control: los accesos, recursos y la integridad de los datos son
controlados por el servidor de forma que un programa cliente defectuoso o no
autorizado no pueda da˜nar el sistema.
Escalabilidad: se puede aumentar la capacidad de clientes y servidores de forma
independiente.
Figura 2.1: Arquitectura cliente-servidor.
2.1.2. La programaci´on estructurada
La programaci´on estructurada es un paradigma de programaci´on, cuya principal
finalidad es la elaboraci´on de programas de f´acil comprension. Para ello, utiliza ´unicamente
12. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 10
tres estructuras de contro b´asicas (secuencial, selectiva e iterativa), siendo innecesario y no
permiti´endose el uso de instrucciones de transferencia incondicional (el repudiado GOTO).
Combinando esquemas sencillos, se pueden llegar a construir sistemas amplios y complejos
pero de f´acil entendimiento.
La programaci´on estructurada se basa en una metodolog´a de refinamientos sucesivos:
se plantea una operaci´on como un todo, y se divide en segmentos m´as sencillos o de
menor complejidad. Una vez terminados todos los segmentos del programa, se procede
a unificar dichos segmento. Aplicando los principios de este paradigma, esta integracion
debe resultar en un proceso sencillo, carente de problemas y, en caso de que hubiera alg´un
problema, ser´a rapidamente detectable para su correccion.
Los beneficios de emplear este paradigma de programaci´on son los siguientes:
Los programas son m´as f´aciles de entender, ya que pueden ser le´ıdo de forma
secuencial, sin necesidad de hacer seguimiento a saltos de l´ınea (GOTO) dentro
bloques de c´odigo para entender la l´ogica.
La estructura del programa es m´as clara puesto que las instrucciones est´an m´as
ligadas o relacionadas entre s´ı.
Reducci´on del esfuerzo en las pruebas. El seguimiento de las fallas (debugging) se
facilita debido a la l´ogica m´as visible, por lo que los errores se pueden detectar y
corregir m´as f´acilmente.
Reducci´on de los costos de mantenimiento.
Programas m´as sencillos y m´as r´apidos.
Los bloques de c´odigo son auto explicativos, lo que apoya a la documentaci´on.
2.1.3. La programaci´on orientada a objetos
La Programaci´on Orientada a Objetos es un paradigma de programaci´on que define
los programas en t´erminos de clases de objetos, objetos que son entidades que combinan
estado (es decir, datos), comportamiento (esto es, procedimientos o m´etodos) e identidad
(propiedad del objeto que lo diferencia del resto). La programaci´on orientada a objetos
expresa un programa como un conjunto de estos objetos, que colaboran entre ellos
para realizar tareas. Esto permite hacer los programas y m´odulos m´as f´aciles de
escribir, mantener y reutilizar. De esta forma, un objeto contiene toda la informaci´on,
(los denominados atributos) que permite definirlo e identificarlo frente a otros objetos
pertenecientes a otras clases (e incluso entre objetos de una misma clase, al poder
tener valores bien diferenciados en sus atributos). A su vez, dispone de mecanismos de
interacci´on (los llamados m´etodos) que favorecen la comunicaci´on entre objetos (de una
misma clase o de distintas), y en consecuencia, el cambio de estado en los propios objetos.
Esta caracter´ıstica lleva a tratarlos como unidades indivisibles, en las que no se separan
(ni deben separarse) informaci´on (datos) y procesamiento (m´etodos).
Este planteamiento difiere de la programaci´on estructurada tradicional, en la que los
datos y los procedimientos est´an separados y sin relaci´on, ya que lo ´unico que se busca es
13. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 11
el procesamiento de unos datos de entrada para obtener otros de salida. La programaci´on
estructurada anima al programador a pensar sobre todo en t´erminos de procedimientos o
funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan.
En la programaci´on estructurada se escriben funciones y despu´es les pasan datos. Los
programadores que emplean lenguajes orientados a objetos definen objetos con datos y
m´etodos y despu´es env´ıan mensajes a los objetos diciendo que realicen esos m´etodos en
s´ı mismos.
Los mayores beneficios que reporta el usar este paradigma de programaci´on, son los
siguientes:
Mejora la calidad del software generado.
Acorta el tiempo de desarrollo.
Aumenta la productividad.
Da pie a la reutilizaci´on del software generado.
2.2. Metodolog´ıa: eXtreme Programming
Las pautas seguidas en el desarrollo de la aplicaci´on se corresponden con esta
metodolog´ıa.
La programaci´on extrema o eXtreme Programming (XP) es un enfoque de la ingenier´ıa
de software formulado por Kent Beck, autor del primer libro sobre la materia [2]. Es el m´as
destacado de los procesos ´agiles de desarrollo de software. La programaci´on extrema se
diferencia de las metodolog´ıas tradicionales principalmente en que pone m´as ´enfasis en la
adaptabilidad que en la previsibilidad. Los defensores de XP consideran que los cambios
de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del
desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en
cualquier punto de la vida del proyecto es una aproximaci´on mejor y m´as realista que
intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos despu´es
en controlar los cambios en los requisitos. Se puede considerar la programaci´on extrema
como la adopci´on de las mejores metodolog´ıas de desarrollo de acuerdo a lo que se pretende
llevar a cabo con el proyecto, y aplicarlo de manera din´amica durante el ciclo de vida del
software. La figura 2.2 ilustra el flujo de esta metodolog´ıa.
Las caracter´ısticas fundamentales de esta metodolog´ıa son:
Desarrollo iterativo e incremental: peque˜nas mejoras, unas tras otras.
Pruebas unitarias continuas, frecuentemente repetidas y automatizadas, incluyendo
pruebas de regresi´on. Se aconseja escribir el c´odigo de la prueba antes de la
codificaci´on.
Frecuente interacci´on del equipo de programaci´on con el cliente o usuario. Se
recomienda que un representante del cliente trabaje junto al equipo de desarrollo.
14. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 12
Figura 2.2: Workflow de la metodolog´ıa XP
Correcci´on de todos los errores antes de a˜nadir nueva funcionalidad.
Hacer entregas frecuentes.
Refactorizaci´on del c´odigo: reescribir ciertas partes del c´odigo para aumentar su
legibilidad y mantenibilidad pero sin modificar su comportamiento. Las pruebas
han de garantizar que en la refactorizaci´on no se ha introducido ning´un fallo.
Propiedad del c´odigo compartida: en vez de dividir la responsabilidad en el desarrollo
de cada m´odulo en grupos de trabajo distintos, este m´etodo promueve el que todo
el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes
pruebas de regresi´on garantizan que los posibles errores ser´an detectados.
Simplicidad en el c´odigo: es la mejor manera de que las cosas funcionen. Cuando todo
funcione se podr´a a˜nadir funcionalidad si es necesario. La programaci´on extrema
apuesta que es m´as sencillo hacer algo simple y tener un poco de trabajo extra para
cambiarlo si se requiere, que realizar algo complicado y quiz´as nunca utilizarlo.
La simplicidad y la comunicaci´on son extraordinariamente complementarias. Con m´as
comunicaci´on resulta m´as f´acil identificar qu´e se debe y qu´e no se debe hacer. Mientras
m´as simple es el sistema, menos tendr´a que comunicar sobre este, lo que lleva a una
comunicaci´on m´as completa, especialmente si se puede reducir el equipo de programadores.
15. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 13
2.3. Lenguaje de programaci´on: PHP
PHP es un lenguaje de programaci´on usado frecuentemente para la creaci´on de
contenido para sitios web con los cuales se puede programar las paginas html y los c´odigos
de fuente. PHP es un acr´onimo recursivo que significa PHP Hypertext Pre-processor
(inicialmente PHP Tools, o, Personal Home Page Tools), y se trata de un lenguaje
interpretado usado para la creaci´on de aplicaciones para servidores, y la generaci´on de
contenido din´amico para sitios web, principalmente. ´Ultimamente, se emplea tambi´en para
la creaci´on de otro tipo de programas, incluyendo aplicaciones con interfaz gr´afica usando
las librer´ıas Qt o GTK+.
El f´acil uso y la similitud con los lenguajes m´as comunes de programaci´on estructurada,
como C y Perl, permiten a la mayor´ıa de los programadores experimentados crear
aplicaciones complejas con una curva de aprendizaje muy suave. Tambi´en les permite
involucrarse con aplicaciones de contenido din´amico sin tener que aprender todo un nuevo
grupo de funciones y pr´acticas.
Debido al dise˜no de PHP, tambi´en es posible crear aplicaciones con una interfaz
gr´afica para el usuario (tambi´en llamada GUI), utilizando la extensi´on PHP-Qt o PHP-
GTK. Tambi´en puede ser usado desde la l´ınea de ´ordenes, de la misma manera como
Perl o Python pueden hacerlo, esta versi´on de PHP se llama PHP CLI (Command Line
Interface).
Su interpretaci´on y ejecuci´on se realiza en el servidor web, en el cual se encuentra
almacenado el script, y el cliente s´olo recibe el resultado de la ejecuci´on. Cuando el cliente
hace una petici´on al servidor para que le env´ıe una p´agina web, generada por un script
PHP, el servidor ejecuta el int´erprete de PHP, el cual procesa el script solicitado que
generar´a el contenido de manera din´amica, pudiendo modificar el contenido a enviar, y
regresa el resultado al servidor, el cual se encarga de envi´arselo al cliente. Adem´as es
posible utilizar PHP para generar archivos PDF, Flash, as´ı como im´agenes en diferentes
formatos, entre otras cosas.
Permite la conexi´on a diferentes tipos de servidores de bases de datos tales como
MySQL, Postgres, Oracle, ODBC, DB2, Microsoft SQL Server, Firebird y SQLite; lo cual
permite la creaci´on de aplicaciones web muy robustas.
PHP tambi´en tiene la capacidad de ser ejecutado en la mayor´ıa de los sistemas
operativos tales como UNIX (y de ese tipo, como Linux o Mac OS X) y Windows, y
puede interactuar con los servidores de web m´as populares ya que existe en versi´on CGI,
m´odulo para Apache, e ISAPI.
El modelo PHP puede ser visto como una alternativa al sistema de Microsoft que
utiliza ASP.NET/C#/VB.NET, a ColdFusion de la compa˜n´ıa Adobe (antes Macromedia),
a JSP/Java de Sun Microsystems, y al famoso CGI/Perl.
Las ventajas de este lenguaje de programaci´on son:
Es un lenguaje multiplataforma.
16. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 14
Capacidad de conexi´on con la mayor´ıa de los manejadores de base de datos que se
utilizan en la actualidad, destaca su conectividad con MySQL.
Leer y manipular datos desde diversas fuentes, incluyendo datos que pueden ingresar
los usuarios desde formularios HTML.
Capacidad de expandir su potencial utilizando la enorme cantidad de m´odulos
(llamados ext’s o extensiones).
Posee una amplia documentaci´on en su p´agina oficial[3], entre la cual se destaca
que todas las funciones del sistema est´an explicadas y ejemplificadas en un ´unico
archivo de ayuda.
Es libre, por lo que se presenta como una alternativa de f´acil acceso para todos.
Permite las t´ecnicas de Programaci´on Orientada a Objetos.
Biblioteca nativa de funciones sumamente amplia e incluida.
No requiere definici´on de tipos de variables ni manejo detallado del bajo nivel.
2.4. Tecnolog´ıas y est´andares
A continuaci´on se describen las tecnolog´ıas y est´andares que han sido empleadas en
este proyecto.
2.4.1. El protocolo HTTP
El Protocolo de Transferencia de Hipertexto (Hypertext Transfer Protocol: HTTP) es
un protocolo del nivel de aplicaci´on para sistemas distribuidos de informaci´on de diversos
tipos.
La versi´on 1.0 se public´o en el Request For Comments (RFC) n´umero 1945; la versi´on
1.1 fue publicada en el RFC n´umero 2068 [1].
Es un protocolo de solicitud/respuesta. Un cliente env´ıa una solicitud a un servidor
en forma de un m´etodo de solicitud, un identificador del elemento solicitado, una versi´on
de protocolo y un mensaje de formato equiparable al MIME (Multipurpose Internet Mail
Extensions) con modificadores a la solicitud para ser m´as expl´ıcitos. El servidor responde
con un estado de la l´ınea de conexi´on, incluyendo la versi´on del protocolo con la que se
responde, un c´odigo de aprobaci´on o error, y un mensaje de formato equiparable al MIME,
conteniendo la informaci´on del servidor, metainformaci´on de la entidad, y posiblemente
un cuerpo del recurso solicitado.
Ha sido usado por la World Wide Web desde 1990. La primera versi´on de HTTP
(la 0.9) era un simple protocolo para el almacenamiento de datos transferidos a trav´es de
Internet. HTTP/1.0 mejor´o el protocolo, permitiendo mensajes en un formato equiparable
al MIME, conteniendo metainformaci´on sobre los datos transferidos y modificadores en
el significado de la solicitud o de la respuesta. En cualquier caso HTTP/1.0 no tiene en
17. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 15
Figura 2.3: Ejemplo de petici´on y respuesta del protocolo HTTP.
consideraci´on los efectos de salva de documentos, los proxies, la necesidad de conexiones
persistentes o la existencia de hosts virtuales. Por todo ello surgi´o la versi´on 1.0.
En la pr´actica, los sistemas de informaci´on requieren m´as funcionalidad que la simple
recuperaci´on, incluyendo b´usqueda y anotaciones. HTTP permite un conjunto de m´etodos
que indican m´as puntualmente qu´e es lo que se solicita. Utiliza URIs URLs y URNs
(Uniform Resource Identifier/Location/Name), para indicar con exactitud a qu´e recurso
se le aplica una determinada solicitud.
HTTP tambi´en es utilizado como un protocolo gen´erico para las comunicaciones, entre
agentes (recuperadores, navegadores....), proxies, pasarelas y otros sistemas de Internet,
incluyendo aquellos que soportan los protocolos SMTP (Simple Mail Transfer Protocol),
FTP (File Transfer Protocol), Gopher, WAIS y NNTP.
2.4.2. XHTML
XHTML, acr´onimo ingl´es de eXtensible Hypertext Markup Language (lenguaje
extensible de marcado de hipertexto), es el lenguaje de marcado pensado para sustituir a
HTML como est´andar para las p´aginas web. XHTML es la versi´on XML de HTML, por
lo que tiene, b´asicamente, las mismas funcionalidades, pero cumple las especificaciones,
m´as estrictas, de XML. Su objetivo es avanzar en el proyecto del World Wide Web
Consortium de lograr una web sem´antica, donde la informaci´on, y la forma de presentarla
est´en claramente separadas. En este sentido, XHTML servir´ıa ´unicamente para transmitir
la informaci´on que contiene un documento, dejando para hojas de estilo (como las hojas
de estilo en cascada) y JavaScript su aspecto y dise˜no en distintos medios (ordenadores,
PDAs, tel´efonos m´oviles, impresoras...).
XHTML es el sucesor de HTML. Es por eso que muchos lo consideran la versi´on
actual del HTML, pero es una recomendaci´on aparte y a la vez paralela; la W3C contin´ua
recomendando el uso de XHTML 1.1, XHTML 1.0, y HTML 4.01 para publicar en la web.
18. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 16
La necesidad de una versi´on m´as estricta de HTML se sinti´o principalmente porque el
contenido de la World Wide Web ahora puede visualizarse desde numerosos dispositivos
(como m´oviles) aparte de los ordenadores tradicionales, donde no pueden dedicarse
recursos suplementarios para afrontar la complejidad a˜nadida de la sintaxis del HTML.
Las principales ventajas del XHTML sobre otros formatos son:
Compatibilidad parcial con navegadores antiguos: la informaci´on se visualiza,
aunque sin formato. Cabe apuntar que el XHTML 1.0 fue dise˜nado expresamente
para ser mostrado en navegadores que soportan HTML de base.
Un mismo documento puede adoptar dise˜nos radicalmente distintos en diferentes
dispositivos, pudiendo incluso escogerse entre varios dise˜nos para un mismo medio.
Facilidad de edici´on directa del c´odigo y de mantenimiento.
Formato abierto, compatible con los nuevos est´andares que actualmente
est´a desarrollando el W3C como recomendaci´on para futuros agentes de usuario
o navegadores.
Los documentos escritos conforme a XHTML 1.0 pueden potencialmente presentar
mejor rendimiento en las actuales herramientas web que aquellos escritos conforme
a HTML.
El W3C dispone de una serie de herramientas, denominados validadores, que
permiten verificar si los documentos generados son conformes a los est´andares que dicha
organizaci´on promueve. En este caso, las p´aginas generadas pasan sin ning´un tipo de
problema las pruebas de validaci´on.
Figura 2.4: Las p´aginas generadas cumplen con el est´andar XHTML.
2.4.3. XML
XML, siglas en ingl´es de eXtensible Markup Language (lenguaje de marcas extensible),
es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web
19. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 17
Consortium (W3C). Es una simplificaci´on y adaptaci´on del SGML y permite definir la
gram´atica de lenguajes espec´ıficos (de la misma manera que HTML es a su vez un lenguaje
definido por SGML). Por lo tanto XML no es realmente un lenguaje en particular, sino
una manera de definir lenguajes para diferentes necesidades. Algunos de estos lenguajes
que usan XML para su definici´on son XHTML, SVG, MathML.
XML no ha nacido s´olo para su aplicaci´on en Internet, sino que se propone como un
est´andar para el intercambio de informaci´on estructurada entre diferentes plataformas.
Se puede usar en bases de datos, editores de texto, hojas de c´alculo y casi cualquier cosa
imaginable.
XML es una tecnolog´ıa sencilla que tiene a su alrededor otras que la complementan
y la hacen mucho m´as grande y con unas posibilidades mucho mayores. Tiene un papel
muy importante en la actualidad ya que permite la compatibilidad entre sistemas para
compartir la informaci´on de una manera segura, fiable y f´acil. Las ventajas de utilizar
esta tecnolog´ıa son:
Es extensible, lo que quiere decir que una vez dise˜nado un lenguaje y puesto en
producci´on, igual es posible extenderlo con la adici´on de nuevas etiquetas de manera
de que los antiguos consumidores de la vieja versi´on todav´ıa puedan entender el nuevo
formato. El analizador es un componente est´andar, no es necesario crear un analizador
espec´ıfico para cada lenguaje. Esto posibilita el empleo de uno de los tantos disponibles.
De esta manera se evitan bugs y se acelera el desarrollo de la aplicaci´on. Si un tercero
decide usar un documento creado en XML, es sencillo entender su estructura y procesarlo.
Mejora la compatibilidad entre aplicaciones.
2.4.4. CSS
Las hojas de estilo en cascada (Cascading Style Sheets, CSS) son un lenguaje formal
usado para definir la presentaci´on de un documento estructurado escrito en HTML o XML
(y por extensi´on en XHTML). El W3C (World Wide Web Consortium) es el encargado de
formular la especificaci´on de las hojas de estilo que servir´a de est´andar para los agentes
de usuario o navegadores.
La idea subyacente del desarrollo de CSS es separar la estructura de un documento de
su presentaci´on.
La informaci´on de estilo puede ser adjuntada tanto como un documento separado o
en el mismo documento HTML. En este ´ultimo podr´ıan definirse estilos generales en la
cabecera del documento o en cada etiqueta particular mediante el atributo style.
Las ventajas de utilizar CSS son:
Control centralizado de la presentaci´on de un sitio web completo, lo cual agiliza de
forma considerable la actualizaci´on del mismo.
Los Navegadores permiten a los usuarios especificar su propia hoja de estilo local que
ser´a aplicada a un sitio web, con lo que aumenta considerablemente la accesibilidad.
Por ejemplo, personas con deficiencias visuales pueden configurar su propia hoja de
estilo para aumentar el tama˜no del texto o remarcar m´as los enlaces.
20. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 18
Una p´agina puede disponer de diferentes hojas de estilo seg´un el dispositivo que la
muestre o incluso a elecci´on del usuario. Por ejemplo, para ser impresa, mostrada
en un dispositivo m´ovil, o ser le´ıda por un sintetizador de voz.
El documento HTML en s´ı mismo es m´as claro de entender y se consigue reducir
considerablemente su tama˜no.
Hay varias versiones: CSS1 y CSS2, con CSS3 en desarrollo por el World Wide
Web Consortium (W3C). Los navegadores modernos implementan CSS1 bastante bien,
aunque existen peque˜nas diferencias de implementaci´on seg´un marcas y versiones de
los navegadores. CSS2, sin embargo, est´a solo parcialmente implementado en los m´as
recientes.
Figura 2.5: Visualizaci´on de la p´agina sin aplicar y aplicando una hoja de estilos,
respectivamente.
2.4.5. AJAX
AJAX, acr´onimo de Asynchronous JavaScript And XML (JavaScript as´ıncrono y
XML), es una t´ecnica de desarrollo web para crear aplicaciones interactivas. ´Estas se
ejecutan en el cliente, es decir, en el navegador de los usuarios, y mantiene comunicaci´on
as´ıncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre
la misma p´agina sin necesidad de recargarla. Esto significa aumentar la interactividad,
velocidad y usabilidad en la misma.
AJAX es una combinaci´on de tres tecnolog´ıas ya existentes:
XHTML (o HTML) y hojas de estilos en cascada (CSS) para el dise˜no que acompa˜na
a la informaci´on.
Document Object Model (DOM) accedido con un lenguaje de scripting por parte del
usuario, especialmente implementaciones ECMAScript como JavaScript y JScript,
para mostrar e interactuar din´amicamente con la informaci´on presentada.
21. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 19
El objeto XMLHttpRequest para intercambiar datos asincr´onicamente con el
servidor web. En algunos frameworks y en algunas situaciones concretas, se usa
un objeto iframe en lugar del XMLHttpRequest para realizar dichos intercambios.
XML es el formato usado com´unmente para la transferencia de vuelta al servidor,
aunque cualquier formato puede funcionar, incluyendo HTML preformateado, texto
plano, JSON y hasta EBML.
AJAX no constituye una tecnolog´ıa en s´ı, sino que es un t´ermino que engloba a un
grupo de ´estas que trabajan conjuntamente.
Figura 2.6: Comparativa entre el modelo de web cl´asico y un modelo de web AJAX .
2.4.6. Servicios Web
Un servicio web (en ingl´es, Web service) es una colecci´on de protocolos y est´andares
que sirven para intercambiar datos entre aplicaciones. Distintas aplicaciones de software
22. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 20
desarrolladas en lenguajes de programaci´on diferentes, y ejecutadas sobre cualquier
plataforma, pueden utilizar los servicios web para intercambiar datos en redes de
ordenadores como Internet. La interoperabilidad se consigue mediante la adopci´on de
est´andares abiertos. Las organizaciones OASIS y W3C son los comit´es responsables de la
arquitectura y reglamentaci´on de los servicios Web. Para mejorar la interoperabilidad
entre distintas implementaciones de servicios Web se ha creado el organismo WS-I,
encargado de desarrollar diversos perfiles para definir de manera m´as exhaustiva estos
est´andares.
La principal raz´on para usar servicios Web es que se basan en HTTP sobre TCP
(Transmission Control Protocol) en el puerto 80. Dado que las organizaciones protegen
sus redes mediante firewalls -que filtran y bloquean gran parte del tr´afico de Internet-
, cierran casi todos los puertos TCP salvo el 80, que es, precisamente, el que usan los
navegadores. Los servicios Web se enrutan por este puerto, por la simple raz´on de que no
resultan bloqueados.
Otro buen motivo por que el usar servicios web es que pueden aportar gran
independencia entre la aplicaci´on que usa el servicio Web y el propio servicio. De esta
forma, los cambios a lo largo del tiempo en uno no deben afectar al otro. Esta flexibilidad
ser´a cada vez m´as importante, dado que la tendencia a construir grandes aplicaciones a
partir de componentes distribuidos m´as peque˜nos es cada d´ıa m´as acusada.
Otras de las ventajas de utilizar servicios web son
Aportan interoperabilidad entre aplicaciones de software independientemente de sus
propiedades o de las plataformas sobre las que se instalen.
Los servicios Web fomentan los est´andares y protocolos basados en texto, que hacen
m´as f´acil acceder a su contenido y entender su funcionamiento.
Al apoyarse en HTTP, los servicios Web pueden aprovecharse de los sistemas de
seguridad firewall sin necesidad de cambiar las reglas de filtrado.
Permiten que servicios y software de diferentes compa˜n´ıas ubicadas en diferentes
lugares geogr´aficos puedan ser combinados f´acilmente para proveer servicios
integrados.
2.4.7. Podcasting
El podcasting consiste en la creacion archivos de sonido (generalmente en formato mp3
u ogg) y de video (llamados videocasts o vodcasts) y distribuirlos mediante un archivo
RSS de manera que permita suscribirse y usar un programa que lo descargue para que el
usuario lo escuche en el momento que quiera, generalmente en un reproductor port´atil.
Un podcast es como una suscripci´on a un audio magazine: el suscriptor recibe
programas de audio via internet para que pueda escucharlos a su conveniencia. La
palabra es una combinaci´on de dos t´erminos: iPod (dispositivo para musica)y broadcasting
(distribuci´on de audio, video...).
23. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 21
El podcast difiere de los tradicionales m´etodo de audio por Internet en dos cosas. En
el pasado, los oyentes ten´ıan que escuchar la radio en Internet dentro de un horario, o
como alternativa, deb´ıan bajarse archivos individuales desde p´aginas web. El Podcasts
es m´as flexible y m´as facil de operar. Los usuarios pueden escuchar una canci´on en
cualquier momento en el ordenador o en un dispositivo portatil de m´usica, y las canciones
o programas de radio son entregadas autom´aticamente a los suscriptores, sin que sea
necesario descargar previamente la m´usica.
Los contenidos de los podcast son muy diversos, pero por lo general suele ser una
persona hablando un tema particular. Esta es la definici´on base. Ahora bien, puede
ser ampliada de diferentes maneras. Hay podcasts sobre diversos temas, especialmente
sobre tecnolog´ıa. Algunos prefieren usar un gui´on, y otros hablan a capella y de forma
improvisada. Algunos parecen un programa de radio, intercalando m´usica, mientras que
otros hacen podcasts m´as cortos y exclusivamente con voz, igual que con los weblogs.
2.5. Herramientas
En esta secci´on se detallan los programas requeridos por la aplicaci´on.
2.5.1. Servidor web: Apache
El servidor HTTP Apache es un software (libre) servidor web de c´odigo abierto para
plataformas Unix (BSD, GNU/Linux, etc.), Windows, Macintosh y otras, que implementa
el protocolo HTTP/1.1 y la noci´on de sitio virtual. Cuando comenz´o su desarrollo en 1995,
se bas´o inicialmente en c´odigo del popular NCSA HTTPd 1.3, pero m´as tarde fue reescrito
por completo. Su nombre se debe a que originalmente Apache consist´ıa solamente en un
conjunto de parches a aplicar al servidor de NCSA. Era, en ingl´es, a patchy server (un
servidor parcheado).
Apache tiene amplia aceptaci´on en la red: en el 2005, Apache es el servidor HTTP
m´as usado, siendo el servidor HTTP del 48 % de los sitios web en el mundo, aunque
en la actualidad su cuota de mercado experimenta un decremento (seg´un las estad´ısticas
hist´oricas y de uso diario proporcionadas por Netcraft), en detrimento de otros servidores,
como Internet Information Server de Microsoft.
La arquitectura del servidor Apache es muy modular. El servidor consta de una secci´on
core, y mucha de la funcionalidad que podr´ıa considerarse b´asica para un servidor web,
es provista por m´odulos. Algunos de estos m´odulos son:
mod ssl : Comunicaciones Seguras v´ıa TLS.
mod rewrite : reescritura de direcciones servidas (generalmente utilizado para
transformar p´aginas din´amicas como PHP en p´aginas est´aticas HTML para
as´ı enga˜nar a los navegantes o a los motores de b´usqueda en cuanto a como fueron
desarrolladas estas p´aginas).
mod dav : Soporte del protocolo WebDAV (RFC 2518).
24. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 22
mod deflate : Compresi´on transparente con el algoritmo deflate del contenido
enviado al cliente.
mod auth ldap : Permite autentificar usuarios contra un servidor LDAP.
mod proxy ajp : Conector para enlazar con el servidor Jakarta Tomcat de p´aginas
din´amicas en Java (servlets y JSP).
Las principales ventajas de este software son:
Dise˜no altamente modular.
Open source.
Multi-plataforma.
Extensible.
Alta popularidad (es relativamente f´acil conseguir ayuda o soporte).
Gratuito.
2.5.2. Sistema Gestor de Bases de Datos: MySQL
MySQL es un sistema de gesti´on de base de datos relacional, multihilo y multiusuario
con m´as de seis millones de instalaciones. MySQL AB desarrolla MySQL como software
libre en un esquema de licenciamiento dual. Por un lado, se ofrece bajo la GNU GPL,
pero las empresas que quieran incorporarlo en productos privativos deben comprar a la
empresa MySQL AB una licencia que les permita ese uso.
Al contrario que proyectos como Apache, donde el software es desarrollado por una
comunidad p´ublica, y el copyright del c´odigo est´a en poder del autor individual, MySQL es
propiedad y est´a patrocinado por una empresa privada, que posee el copyright de la mayor
parte del c´odigo. Esto es lo que posibilita el esquema de licenciamiento anteriormente
mencionado. Adem´as de la venta de licencias privativas, la compa˜n´ıa ofrece soporte y
servicios. Para sus operaciones contratan trabajadores alrededor del mundo que colaboran
v´ıa Internet.
MySQL es muy utilizado en aplicaciones web como MediaWiki o Drupal, en
plataformas LAMP y WAMP (Linux/Windows-Apache-MySQL-PHP/Perl/Python), y en
herramientas de seguimiento de errores, como Bugzilla. Su popularidad como aplicaci´on
web est´a muy ligada a PHP, que a menudo aparece en combinaci´on con MySQL. MySQL
es una base de datos muy r´apida en la lectura cuando utiliza el motor no transaccional
MyISAM, pero puede provocar problemas de integridad en entornos de alta concurrencia
en la modificaci´on. En aplicaciones web hay baja concurrencia en la modificaci´on de datos,
y en cambio el entorno es intensivo en lectura de datos, lo que hace a MySQL ideal para
este tipo de aplicaciones.
La licencia GNU GPL de MySQL obliga a distribuir cualquier producto derivado
(aplicaci´on) bajo esa misma licencia. Si un desarrollado desea incorporar MySQL en su
producto pero no desea distribuirlo bajo licencia GNU GPL, dede adquirir la licencia
comercial de MySQL.
25. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 23
2.5.3. Servidor streaming: Icecast
Icecast es un proyecto para streaming de medios mantenido por la Fundaci´on Xiph.org.
Se trata de un software muy vers´atil, ya que los nuevos formatos de audio se pueden
agregar relativamente f´acil, y soporta est´andares abiertos para comunicaci´on e interacci´on.
Tambi´en se refiere espec´ıficamente al programa servidor que es parte del proyecto.
Actualmente el servidor Icecast soporta en sus ´ultimas versiones streams Ogg Vorbis,
MP3, Ogg Speex, Ogg FLAC, Ogg Theora y AAC.
El servidor Icecast tiene una funcionalidad similar al programa propietario de servidor
de medios SHOUTcast de Nullsoft y es compatible con ´este.
Existen dos partes claramente diferenciadas dentro del servidor de streaming: la parte
servidora y la parte cliente.
Figura 2.7: Esquema de un servidor de streming Icecast
El servidor Icecast, es el encargado del env´ıo continuado del flujo de audio (stream)
a los oyentes virtuales. En una configuraci´on t´ıpica, suele ser com´un el uso de un solo
servidor.
El servidor tambi´en realiza las tareas de autentificar usuarios y grupos (tanto de
clientes como de proveedores de audio), informar en vivo a los directorios de emisoras
Icecast de su estado en concreto, con informaci´on tal como los programas que se est´an
emitiendo, el n´umero de oyentes, calidad de la emisi´on, etc.
Existe la posibilidad de servir varios flujos a la vez, es decir, un mismo servidor es
capaz de emitir flujos de diferentes clientes Icecast, posibilitando la coexistencia de varias
emisoras en un ´unico servidor.
26. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 24
Los clientes de Icecast (como, por ejemplo, Ezstream) son las aplicaciones responsables
de codificar en el formato del flujo (por ejemplo, un fichero wma a mp3, o un mp3 de
radio 320Kbps a mp3 de ratio 128 Kbps) y enviarlo a los servidores Icecast. Existen dos
modos de enviar los flujos de audio de los clientes al servidor, diferenciados por el origen
de la entrada del audio:
1. Flujos creados a partir de ficheros mp3. El cliente Icecast crea un flujo a partir
de una lista de ficheros MP3. Estos ficheros ser´an todos enviados a un ratio de
bits especificado al comienzo (por defecto, 128 kbps constantes). Si los ficheros no
han sido codificados a ese ratio pueden suceder hecho inesperados al reproducirse
(paradas, aceleraciones del sonido, etc). Algunos de estos clientes tienen la capacidad
de recodificar estos ficheros MP3 para adecuarlos al formato establecido en el
servidor, pero incrementan notablemente el consumo de recursos de la m´aquina
en que se ejecuta.
2. Creaci´on al vuelo. Permite introducir sonido desde una conexi´on externa a partir
de la tarjeta de sonido. Tambi´en existe la posibilidad de crear el flujo a partir de
la mezcla de diferentes or´ıgenes, lo significa que se puede utilizar el micr´ofono para
hacer emisiones en vivo y tambi´en utilizar multi-canal para mezclar canciones y
codificarlo a un ratio especifico para el env´ıo a un servidor Icecast.
Aunque en s´ı el producto no tiene un tope de oyentes al que servir, suele ser com´un
que el cuello de botella se encuentre en el ancho de banda de la red. Para ello es posible
varias soluciones:
Reducir la calidad de emisi´on. Icecast permite variar la calidad de la emisi´on. Si
se reduce la calidad de emisi´on, la cantidad de ancho de banda requerido por los
oyentes es menor, con lo que se puede emitir a un mayor n´umero de oyentes con el
mismo ancho de banda.
Limitar el numero de oyentes. Esta opci´on permite que la calidad de la transmisi´on
no se deteriore; cuando el n´umero de oyentes llega a un l´ımite, no se admiten m´as
conexiones hasta que el n´umero sea inferior al establecido como cota.
Redundancia de servidores. El sistema permite que se despliegue una estructura
arborescente de servidores que reciben el flujo unos de otros. En un escenario tipico,
si el enlace del servidor maestro queda saturado, un servidor esclavo puede recoger
el flujo y servirlo a mas clientes.
El equipo m´ınimo para un servidor puede ser incluso un 486 con 32 Mb de RAM,
pero el n´umero de clientes depende de la calidad a la que se desea emitir, del n´umero de
oyentes y del n´umero de emisoras/flujos de audio.
En nuestro caso en particular, la principal limitaci´on viene dada por el ancho de banda
m´aximo soportado por el servidor de radio: 100Mbps. La red de la Universidad Rey Juan
Carlos ofrece 1 Gbps, pero la limitaci´on del ancho de banda la impone el menor de los
valores que conforman el canal, que en este caso viene dado por el hardware de la tarjeta
27. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 25
de red del servidor. A´un as´ı, este ancho de banda permite dar soporte hasta unos 700
usuarios, n´umero de oyentes que excede las previsiones m´as optimistas.
Todos los par´ametros de configuraci´on (puerto del servidor, l´ımite de clientes, usuario
y password del administrador) se establecen en un fichero xml.
2.5.4. Codificador de audio: Ezstream
Ezstream es un cliente de l´ınea de comandos encargado de producir flujos (streams)
multimedia para servidores de streaming multimedia Icecast. Comenz´o como el sucesor
de la antigua utilidad shout, y, desde entonces, ha sido ampliado con numerosas y ´utiles
funcionalidades.
En su modo de operaci´on b´asico, se ocupa de crear streams a partir de ficheros de
audio/video o desde una entrada est´andar, sin la necesidad de recodificar dichos datos,
lo cual se traduce en un m´ınimo consumo de recursos del sistema. Tambi´en permite usar
varios decodificadores y encoders para recodificar de un formato a otro, y encauzar el
flujo resultante a un servidor Icecast. Otras caracter´ısticas adicionales son el manejo
de metadatos (etiquetas ID3 de los ficheros) y la creaci´on de listas de reproducci´on
(playlist) programables. Todas estas caracter´ısticas hacen de Ezstream un emisor de flujos
multimedia muy flexible y vers´atil.
Los formatos soportados para el streaming son MP3, Ogg Vorbis y Ogg Theora. De
manera nativa, s´olo ofrece soporte para metadatos de MP3 (s´olo la versi´on 1 de ID3)
y Ogg Vorbis, aunque si se compila Ezstream con el soporte de la librer´ıa TagLib (de
manera opcional), ser´a capaz de acceder a los metadatos de un gran n´umero de distintos
formatos (FLAC, APE, AAC, WMA, etc.).
Ezstream es software libre, y distribuido bajo la licencia GNU General Public License.
Figura 2.8: Esquema b´asico de clientes Ezstream y el servidor Icecast
28. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 26
2.5.5. Librer´ıas de terceras partes
La complejidad de algunas de las tareas a realizar (por ejemplo, el an´alisis de los
ficheros de audio para comprobar que cumplen con los requisitos t´ecnicos necesarios para
poder ser emitidos) hacen necesario el uso de librer´ıas de terceras partes. En esta secci´on
se detallan la librer´ıas empleadas y su utilidad.
2.5.5.1. getID3()
Los ficheros de audio deben cumplir una serie de caracter´ısticas para poder ser emitidos
(ver ). Para realizar estas comprobaciones es necesario analizar la metainformaci´on
encapsulada en el fichero de audio; esta metainformaci´on es lo que se conoce como tags
ID3.
ID3[4] es un est´andar de facto para incluir metadatos (etiquetas) en un contenedor
multimedia, tales como duraci´on, bitrate o int´erprete. Esta informaci´on se codifica en la
cabecera del fichero de audio/video, por lo que para poder acceder a ella, hay que conocer
detalladamente la posici´on (offset) en la que se ubica la informaci´on requerida, y saber
interpretar lo que significada cada uno de esos bits.
Figura 2.9: Ejemplo de la disposici´on de la metainformaci´on ID3 en un fichero de audio
getID3()[5] es una librer´ıa open-source, independiente de la plataforma y escrita en
PHP, creada por James Heinrich y Allan Hansen, distribuida bajo licencia GPL. getID3()
permite extraer y modificar la metainformaci´on de diversos formatos multimedia (audio,
video e im´agenes) haciendo uso de las clases (y los respectivos m´etodos) que la librer´ıa
ofrece.
2.5.5.2. NuSOAP
nuSOAP[6] es una reimplementaci´on de la librer´ıa SOAPx4 por parte de NuSphere
y Dietrich Ayala. nuSOAP es un conjunto de clases PHP - no requiere de ninguna otra
extensi´on PHP - que permite a los desarrolladores crear y consumir servicios web basados
en los est´andares SOAP 1.1, WSDL 1.1 y HTTP 1.X.
29. CAP´ITULO 2. TECNOLOG´IAS Y HERAMIENTAS EMPLEADAS 27
SOAP (siglas de Simple Object Access Protocol) es un protocolo est´andar creado
por Microsoft, IBM y otros, est´a actualmente bajo el auspicio de la W3C que define
c´omo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de
datos XML. SOAP es un marco extensible y descentralizado que permite trabajar sobre
m´ultiples pilas de protocolos de redes inform´aticas.
A diferencia de DCOM y CORBA, que son binarios, SOAP usa el c´odigo fuente en
XML. Esto es una ventaja ya que facilita su lectura por parte de humanos, pero tambi´en
es un inconveniente dado que los mensajes resultantes son m´as largos. El intercambio de
mensajes se realiza mediante tecnolog´ıa de componentes.
Figura 2.10: Mensajes SOAP del cliente y del servicio web.
30. Cap´ıtulo 3
N´ucleo del trabajo
3.1. Soluci´on
La aplicaci´on desarrollada busca dar soluci´on a los problemas expuestos en los objetivos
del proyecto, sin perder la noci´on del ´ambito al que est´a destinado: alumnos que cursan
carreras de Ciencias de la informaci´on. La tarea de crear una emisora de radio por Internet
puede resultar compleja sin tener unos conocimientos medios de inform´atica.
Esta plataforma pretender acabar con la laboriosa y tediosa tarea de tener que crear
emisoras de radio, automatizando los procesos y reduciendo todos los esfuerzos a la m´ınima
expresi´on; basta con asignar un nombre de usuario, una contrase˜na, un nombre de emisora
y una breve descripci´on para tener una emisora de radio sobre IP en funcinamiento.
Adem´as, se ha introducido una detallada ayuda en cada secci´on para resolver las dudas
de los usuarios.
El proyecto se divide en dos partes claramente diferenciadas: el back-end y el front-end.
3.1.1. Back-end
El back-end lo constituyen aquellos programas necesarios para el correcto
funcionamiento de la aplicaci´on. La plataforma se apoya en las aplicaciones Icecast y
Ezstream para el streaming del audio, MySQL para la gesti´on de datos del sistema, y
comandos de shell del host de radio para realizar operaciones sobre el sistema de ficheros
y gestionar procesos. Es indispensable el correcto acoplamiento de cada una de las partes
del conjunto para que la plataforma funcione seg´un lo previsto.
La aplicaci´on realiza las tareas de edici´on de los ficheros de configuraci´on de Icecast
(a˜nadiendo los nuevos puntos de montaje para las nuevas emisoras), crear los ficheros de
configuraci´on de Ezstream, gestionar las listas de ficheros que van a ser emitidos, generar
los ficheros XML para ofrecer el servicio de podcast, gestionar el sistema de ficheros para
realizar las operaciones necesarias sobre los ficheros de audio (crear, renombrar o borrar),
e iniciar y detener los procesos de las emisoras.
Las anteriores tareas, aunque son ejecutadas por el propio usuario de la plataforma,
desconoce todos los procesos que se llevan a cabo tan s´olo pulsando sobre un v´ınculo o
28
31. CAP´ITULO 3. N ´UCLEO DEL TRABAJO 29
enviando un formulario de una p´agina web del sitio. Esta abstracci´on se logra gracias al
front-end.
3.1.2. Front-end
El front-end est´a constituido por las p´aginas generadas din´amicamente por el servidor
web Apache, como resultado de la ejecuci´on de los scripts de PHP invocados a trav´es del
navegador, o dicho de una forma m´as coloquial, las p´aginas que solicita el usuario.
A trav´es de un intuitivo interfaz web, el usuario est´a modificando la configuraci´on
de una serie de ficheros del host, arrancando nuevos procesos en una m´aquina remota,
parseando ficheros XML, o invocando un servicio web, sin ser consciente de ello.
3.2. Enfoque
Para el desarrollo del proyecto, se opt´o por seguir una metodolog´ıa ´agil (programaci´on
extrema), ya que no quedaban claramente definidos todos los requisitos de la aplicaci´on,
ni se establece una fecha tope de entrega de la aplicaci´on (si bien es cierto que la beca
de colaboraci´on concluye el 30 de julio de 2007), y se debe observar la evoluci´on del
desarrollo de la aplicaci´on para determinar que funcionalidades se deden a˜nadir, las que
son necesarias modificar, etc.
Hay una serie de requisitos inciales parcialmente definidos, que con el devenir del
proyecto se han ido perfilando. Inicialmente, los requisitos no funcionales son los que
estaban m´as claros: debe usar software libre en todo momento, con la finalidad de reducir
al m´ınimo los costes del desarrollo del software.
Si bien es cierto que las herramientas no deben condicionar el desarrollo de un software,
en este caso en particular se convierte en imprescindible enfocar el proyecto al trabajo con
las herramientas de streaming Icecast y Ezstream, puesto que desarrollar unas aplicaciones
con capacidades similares conlleva una complejidad considerable (y por ende, tiempo y
dinero); se trata de una filosof´ıa de no reinventar la rueda[7].
Los requisitos establecidos en un primer momento son:
1. debe manejarse a trav´es de un interfaz web.
2. debe usar software libre.
3. debe permitir m´ultiples transmisiones de audio de forma simult´anea.
Los dos primeros requisitos condicionan en gran medida los requisitos que pudieran
surgir posteriormente. Los requisitos de usuario se ven afectados a su vez por el primer
requisito no funcional:
32. CAP´ITULO 3. N ´UCLEO DEL TRABAJO 30
1. El usuario debe loguearse en la aplicaci´on, a trav´es de un formulario para tal efecto.
Una vez cumplimentado el formulario, los datos del mismo ser´an procesados; si el
usuario est´a registrado como un usuario del sistema (informaci´on obtenida a trav´es
de una consulta a la base de datos), se iniciar´a una sesi´on y el usuario ser´a dirigido al
“panel de control” de la aplicaci´on (que en funci´on del tipo de perfil, mostrar´a unas
determinadas opciones). En caso de que no est´e registrado, o introdujera unos datos
err´oneos, se mostrar´a el correspondiente mensaje de advertencia, y se le ofrecer´a la
posibilidad de intentar acceder nuevamente al sistema.
2. El “panel de control” de la aplicaci´on debe permitir el acceso directo a las
operaciones permitidas por la aplicaci´on, al apartado de ayuda, y la opci´on de
terminar la sesi´on.
3. A trav´es un formulario web con un campo del tipo file, el usuario debe poder subir
los ficheros de audio que incluir´a en su emisora. Tras pulsar en el bot´on Examinar,
el usuario debe elegir en el cuadro de di´alogo que aparece el fichero mp3 que quiere
incluir en su emisi´on. Una vez subido al servidor, aparecer´a un mensaje que notifica
si la subida del fichero fue exitosa o bien se produjo alg´un tipo de problema (un
formato de audio no v´alido, un bitrate distinto al requerido, etc). En caso de que
tenga ´exito la transferencia, en la tabla de contenidos de la playlist aparecer´a dicho
fichero, se anota la informaci´on en la base de datos, y se incrementa el contador de
la cuota de disco del usuario.
4. En la tabla de contenidos de la playlist, a trav´es de un formulario web se debe
poder establecer el orden de reproducci´on de los ficheros de la emisora. Mediante un
n´umero del 1 al n (siendo n el n´umero total de ficheros de la emisora) se establece
el orden en la lista de reproducci´on. Estableciendo un valor de orden 0, se indica
que dicho fichero no ser´a reproducido. En caso de empates de prioridades, se toma
como criterio el orden alfab´etico.
5. El comienzo y fin de una emisi´on se debe producir pulsando en los respectivos
v´ınculos del panel de control. En caso de que la emisi´on no de comienzo por alg´un
problema de ´ındole t´ecnico (por ejemplo, que no haya ficheros a reproducir), se
mostrar´a el pertinente mensaje de error. Cuando se inicie la emisi´on, debe mostrarse
alg´un indicador en el panel de control que notifique al usuario el hecho.
6. La opci´on de crear una nueva emisora s´olo estar´a disponible para administradores.
Proveer´a un formulario, en el que se solicitar´an los datos necesarios para crear un
usuario en el sistema con una emisora asociada (i.e, nombre del usuario, password,
nombre de la emisora, direcci´on de correo para poder contactar con el usuario, perfil
y una breve descripci´on de la emisora). En caso de que el proceso concluya de forma
exitosa, se enviar´a una notificaci´on v´ıa e-mail al administrador y al usuario.
7. Se debe proporcionar una opci´on para que el usuario pueda consultar las estad´ısticas
de su emisora en tiempo real.
8. Un usuario administrador debe poder acceder al servidor Icecast para poder realizar
tareas de gesti´on sobre ´este (por ejemplo, detener una emisi´on, consultar estado de
varias emisoras desde un ´unico punto, etc).
33. CAP´ITULO 3. N ´UCLEO DEL TRABAJO 31
9. Se debe proporcionar una manera de gestionar los ficheros del usuario, que permita
realizar operaciones tales como modificaci´on de la informaci´on asociada al fichero o
borrar ficheros del servidor.
La figura 3.2 condensa en forma de casos de uso los requisitos del usuario:
Figura 3.1: Diagrama de casos de uso.
3.3. Desarrollo
Pese a que la propuesta de este proyecto es aceptada en el mes de junio del curso
pasado, el desarrollo del mismo comienza a finales del mes de marzo de 2006.
Tras un periodo previo de aprendizaje del lenguaje PHP (realizando modificaciones
e implementando nuevas funcionalidades en las aplicaciones de la web del Grupo de
Audiovisuales), retomo el proyecto de la radio, inicialmente asignado a Juan Fabi´an Sim´on,
compa˜nero del Grupo de Audiovisuales que, por motivos personales, renunci´o a la beca
de colaboraci´on.
En este punto, el proyecto est´a en una fase muy prematura (s´olo est´a implementada
de forma parcial la subida de ficheros de audio y la generaci´on de listas de reproducci´on),
pero los experimentos previamente realizados por Juan Fabi´an Sim´on y David P´erez,
permitieron determinar el software que se iba a usar para el apartado de streaming, hecho
crucial para la posterior fase de desarrollo e implementaci´on.
34. CAP´ITULO 3. N ´UCLEO DEL TRABAJO 32
El desarrollo prosigue hasta el mes de junio (fecha de conclusi´on del primer periodo
de la beca de colaboraci´on con el Grupo de Audiovisuales), habiendo completados las
siguientes tareas:
Pasar la aplicaci´on de desarrollo a producci´on (31/03/06).
Documentar el trabajo (31/03/06).
Estudiar formatos de audio (03/04/06).
Creaci´on de la estructura de base de datos, modificando el c´odigo desarrollado para
que mantenga la actual funcionalidad (11/04/06).
A˜nadir a la aplicaci´on la gesti´on de creaci´on de emisoras (´unicamente permitido a
administradores). Al crear una emisora se crea una playlist y un punto de montaje,
y posteriormente se pasa a la creaci´on de un usuario, que se asociar´a a esta emisora
(11/04/06).
A˜nadir un interfaz web m´as elaborado (21/04/06).
Permitir gestionar la cuota de disco a partir de una constante insertada en el fichero
de definici´on de constantes, para posteriormente poder configurar este pa´rametro
v´ıa web (24/04/06).
Al crear una nueva emisora, se generar´a una copia de seguridad del fichero
de configuraci´on de Icecast. El anterior fichero ser´a sobreescrito con la nueva
configuraci´on (nuevo mountpoint de emisora). Mediante un script, se reemplazar´a el
fichero de configuraci´on anterior (en la carpeta s´olo accesible con permisos de root),
por el “nuevo” fichero. Este proceso se realizar´a en un determinado momento de la
madrugada. S´olo es necesario reiniciar el proceso de Icecast, ya que los Ezstream
continuar´an ejecut´andose (04/05/06).
Poder eliminar ficheros de una playlist. Quedar´a borrado del cat´alogo y del disco
(04/05/06).
Comprobar la ejecuci´on de la emisora obteniendo los par´ametros del xml de IceCast,
clientes conectados, fichero en emisi´on, etc... (04/05/06).
Comprobar que los ficheros subidos tengan un nombre con caracteres alfanum´ericos
´unicamente. (04/05/06).
Crear un “totalizador” de tiempos de la playlist (12/05/06).
Controlar el tama˜no m´aximo de fichero, que muestre mensaje de error y no continue
subiendo el fichero al servidor de radio, en caso de sobrepasarlo (12/05/06).
Comprobar que los ficheros subidos cumplen con los requisitos necesarios para ser
emitidos( formato mp3, etc.). Si no cumplen, mensaje de error, y borrado del fichero
en disco y BB.DD. (12/05/06).
Crear una ayuda para la opci´on de subir ficheros y creaci´on de emisoras (16/05/06).
35. CAP´ITULO 3. N ´UCLEO DEL TRABAJO 33
Generar un fichero .m3u que contenga la URL de la emisora, guardard´andolo en el
directorio emisoras (17/05/06).
A˜nadir un bot´on que permita escuchar la emisora y ayuda/explicaci´on de c´omo
crear un enlace a la p´agina web del usuario para conectar a la emisora (17/05/06).
Crear p´agina con listado de todas las emisoras activas y estad´ısticas de oyentes
(18/05/06).
Script preliminar para la instalaci´on de la aplicaci´on. (15/06/06)
Llegado a este punto, se tiene una primera versi´on de la plataforma de radio.
El desarrollo se paraliza durante dos meses, y continuando en el mes de septiembre,
cuando me reincorporo nuevamente como becario del Grupo de Audiovisuales. Sin
embargo, durante este mes no se producen apenas avances en el desarrollo de la plataforma
de radio, ya que la creaci´on de canales RSS para la web de audiovisuales y de varios
cambios en la web de URJC-TV acaparan las horas de trabajo.
En el mes de octubre se retoma el desarrollo del proyecto para realizar nuevos cambios
en la gesti´on de la cuota en disco de la emisora y la refactorizaci´on del c´odigo. En octubre se
presenta la aplicaci´on a un alumno representante de la asociaci´on de radio. En noviembre
tiene lugar una reuni´on con Jos´e Luis Mart´ın S´aez, docente del ´area de Ciencias de la
comunicaci´on, a t´ıtulo informativo del estado actual de la plataforma de radio.
En el mes de diciembre, se comienza a colaborar con el proyecto ARCA, y en los
meses posteriores, se trabaja en un m´odulo de estad´ısticas para dicho proyecto, relegando
el desarrollo de la plataforma de radio a un segundo plano.
En el mes de marzo de 2007, tras concluir una primera versi´on del m´odulo de
estad´ısticas, se retoma nuevamente el proyecto de radio. En los meses de mazo y abril, se
implementa el sistema de podcasting y la catalogaci´on de ficheros de la emisora. En el mes
de abril se realiza la presentaci´on de la plataforma a los profesores del ´area de Ciencias
de la Comunicaci´on.
En mayo, se retoma el desarrollo del m´odulo de estad´ısticas de ARCA, por lo que se
abandona temporalmente el desarrollo de la plataforma.
En junio, prosigue el proyecto de radio para incorparar el servicio web que permite
exportar el cat´alogo de emisoras, puesto que se considera una herramienta interesante
para el posterior uso por parte de los alumnos. En este punto se da por concluido el
desarrollo de este proyecto.
Por ´ultimo, en septiembre de 2007 se finaliza y entrega la memoria, se incluyen los
diferentes documentos generados y se prepara la defensa del proyecto y exposici´on de la
misma.
En el desarrollo se ha hecho un esfuerzo en conseguir que la documentaci´on generada
fuera suficientemente detallada para el mantenimiento del proyecto. As´ı mismo los fuentes
36. CAP´ITULO 3. N ´UCLEO DEL TRABAJO 34
fueron codificados de una manera est´andar y por tanto son f´acilmente comprensibles, para
un programador.
Como en todo desarrollo medianamente serio, se ha adjuntado un manual para facilitar
la instalaci´on (ver A) y el uso del producto (ver B).
37. Cap´ıtulo 4
Descripci´on inform´atica
En esta secci´on se detallan las cuestiones referentes a la implementaci´on de la
plataforma de radio: estructura de la base de datos y del sistema de ficheros, creaci´on
de nuevas emisoras, la gesti´on de procesos de las emisoras, la forma de comunicarse de la
plataforma con las aplicaciones de streaming.
4.1. Estructura de la base de datos
La base de datos que almacena la informaci´on requerida por la aplicaci´on consta de
cuatro tablas, de una estructura s´umamente sencilla:
Figura 4.1: Estructura de la base de datos de la aplicaci´on.
La finalidad de dichas tablas se describe a continuaci´on:
Usuarios: guarda la informaci´on de los usuarios de la plataforma (nombre de usuario,
de la emisora asociada al usuario, contrase˜na de acceso y una direcci´on de correo
35
38. CAP´ITULO 4. DESCRIPCI ´ON INFORM ´ATICA 36
electr´onico). El campo perfil se utiliza como discriminante: permite diferenciar entre
un usuario administrador y un usuario sin privilegios de administraci´on.
Emisoras: contiene el nombre de la emisora, una breve descripci´on, y el punto de
montaje de la emisora (este concepto se explica m´as detalladamente en el apartado
4.5).
Playlist: almacena el nombre de la playlist, la emisora a la que est´a asociada, y la
duraci´on de la misma.
Contenidos: guarda la informaci´on referente a los ficheros que ser´an emitidos
(nombre, tama˜no, duraci´on, descripci´on, fecha de subida, playlist y n´umero de orden
del fichero dentro de dicha playlist).
4.2. Estructura del sistema de ficheros
Los contenidos de la plataforma se almacenan en las rutas indicadas durante el proceso
de instalaci´on de la aplicaci´on. A su vez, esas rutas se asignan a una serie de constantes
en el fichero de configuraci´on data.php, siendo las siguientes las m´as relevantes:
define ("_DIR_APACHE", "/var/www/radiourjc/");
define ("_RUTA_PROGRAMAS", "/home/radiourjc/");
define ("_RUTA_M3U", _DIR_APACHE . "emisoras/");
define ("_RUTA_RSS", _DIR_APACHE . "rss/");
La constante DIR APACHE define la ruta del directorio donde se encuentran los
ficheros que componen el sitio web de la plataforma. Lo habitual es situarlo en
un subdirectorio del par´ametro DocumentRoot especificado en el httpd.conf de
Apache (o si se usa la versi´on 2.X de Apache, en el fichero /etc/apache2/sites-
available/default). El proceso de instalaci´on solicita esta ruta, y autom´aticamente
se configura esta constante en el fichero data.php.
RUTA PROGRAMAS establece el directorio que contendr´a a su vez los subdirectorios
de cada emisora. Dichos subdirectorios contienen los ficheros de la playlist, el fichero
de configuraci´on para Ezstream, y los ficheros de audio que constituyen el cat´alogo
de la emisora.
RUTA M3U es un subdirectorio que pende del directorio donde se instala la
plataforma de radio, que contiene el fichero .m3u de la emisora. El fichero m3u es un
simple fichero de texto que contiene la URL del punto de montaje de la emisora (algo
del estilo http://radio.urjc.es:8000/nombre emisora.mp3). Al abrir este fichero, si
la emisora est´a activa, el oyente escuchar´a la emisi´on.
RUTA RSS es el directorio que contiene los ficheros XML que habilitan el servicio
de podcast de las emisoras de radio.
39. CAP´ITULO 4. DESCRIPCI ´ON INFORM ´ATICA 37
4.3. Creaci´on de nuevas emisoras de radio
El proceso de creaci´on de nuevas emisoras de radio s´olo supone para el administrador
la cumplimentaci´on de un formulario con una serie de datos b´asicos. Sin embargo, conlleva
una serie de tareas para la aplicaci´on:
1. Inserci´on de la nueva informaci´on en la base de datos (previa validaci´on de los datos,
para no permitir direcciones de correo “inv´alidas”, duplicar nombres de usuarios,
etc).
2. Actualizaci´on del fichero de configuraci´on de Icecast para incluir un punto de
montaje para la nueva emisora.
3. Creaci´on del subdirectorio de la emisora, que realizar´a la funci´on de contenedor de
la informaci´on de la emisora: ficheros de configuraci´on de las aplicaciones y ficheros
de audio.
4. Creaci´on del fichero de configuraci´on de Ezstream dentro del subdirectorio de la
emisora.
5. Creaci´on del fichero de la playlist dentro del subdirectorio de la emisora.
6. Creaci´on del fichero .m3u dentro del subdirectirio emisoras del directorio de
instalaci´on de la aplicaci´on.
7. Creaci´on del fichero XML para podcasting en el subdirectirio rss del directorio de
instalaci´on de la aplicaci´on.
8. Env´ıo de un mensaje de notificaci´on al nuevo usuario.
9. Env´ıo de un mensaje de notificaci´on a los administradores.
Todos estos procesos son realizados en un segundo plano, haci´endose notable la utilidad
del front-end de la aplicaci´on, que abstrae de todos estos procesos al usuario. El ´unico
modo de que alguno de los anteriores procesos se manifieste, es en el caso de que se
produzca alg´un tipo de error, ya que la aplicaci´on mostrar´a el oportuno mensaje de error.
4.4. Gesti´on de los procesos de las emisoras
Una emisora de radio es un proceso de Ezstream arrancado en el host. Ezstream lee
un fichero XML de configuraci´on (generado al crear la emisora), en el cual se especifican
detalles tales como el punto de montaje, playlist y password que se usar´an para hacer
llegar el flujo de audio a Icecast.
Icecast, para poder “retransmitir” el flujo de audio que le proporciona Ezstream (o
cuarquier otro source client), debe tener registrado en su fichero de configuraci´on un
punto de montaje para dicho proceso. El punto de montaje es la URL (algo del estilo
http://radio.urjc.es:8000/nombre emisora.mp3) que utiliza Icecast para difundir un flujo
40. CAP´ITULO 4. DESCRIPCI ´ON INFORM ´ATICA 38
Figura 4.2: Fichero de configuraci´on de Ezstream para una emisora.
Figura 4.3: Definici´on del punto de montaje en el fichero de configuraci´on de Icecast.
de audio; en este caso, el flujo que le llega del Ezstream de la emisora. Los oyentes deben
“conectarse” a ese punto de montaje para poder escuchar la emisi´on.
Una emisora se pone en marcha lanzando en background (segundo plano) un proceso
de Ezstream a trav´es de un script PHP (radio onoff.php), pas´andole como par´ametro el
nombre del fichero de configuraci´on. Este mismo script se encarga de “matar” el proceso
de la emisora, invocando una serie de comandos de la shell del host para, pasando una
serie de filtros, obtener el pid del proceso anteriormente arrancado.
Es importante remarcar la necesidad de arrancar la emisora como proceso en segundo
plano, ya que de lo contrario, el script producir´ıa en el navegador web del usuario un
efecto de “carga indefinida” de la p´agina.
41. CAP´ITULO 4. DESCRIPCI ´ON INFORM ´ATICA 39
4.5. Generaci´on de la lista de reproducci´on
Para la generaci´on de la lista de reproducci´on de la emisora, el usuario debe acceder
a trav´es del panel de control a la secci´on habilitada a tal efecto.
Se ofrece un formulario con todos los contenidos del usuario alojados en el servidor, en
un formato de lista. Cada entrada dispone de una lista desplegable que permite establecer
el n´umero de orden dentro de la lista secuencial de ficheros que conforman la programaci´on
de la emisora.
Figura 4.4: Snapshot de una playlist y fichero m3u asociado.
Estableciendo un valor de 0, el usuario indica que no desea incluir ese fichero en la
programaci´on de la emisora. Por defecto, los nuevos contenidos poseen este n´umero de
orden.
Asignando un valor superior a 0, se indica de forma expl´ıcita el orden en que se
reproducir´a el fichero. En caso de asignar un mismo n´umero de orden para dos o m´as
ficheros, se establece un criterio alfab´etico para determinar el orden final.
Una vez establecidos los ´ordenes de reproducci´on de los ficheros, se genera un fichero
de extensi´on .m3u: un fichero de texto plano que contiene las rutas de los ficheros que
ser´an reproducidos, en el orden especificado.
Figura 4.5: Spnashot de la nueva playlist y el fichero m3u generado.
Cuando el usuario env´ıa el formulario, el script playlist.php se encarga de procesar los
datos para generar la nueva lista de reproducci´on, asignar los correspondientes n´umeros de
orden a los ficheros alojados en la base de datos, y visualizar los cambios en el navegador.
42. CAP´ITULO 4. DESCRIPCI ´ON INFORM ´ATICA 40
4.6. Subida de nuevos ficheros y gesti´on de la cuota
de disco
La subida de ficheros se realiza a trav´es de un simple formulario web, en el que el
usuario debe seleccionar en su equipo el fichero que desea alojar en el servidor de radio
para su posterior emisi´on y, de forma opcional, incluir una breve descripci´on del fichero.
Antes de proceder a subir el fichero, se realiza una serie de comprobaciones en el lado del
cliente (v´ıa javascript), consistentes en verificar la extensi´on del fichero (debe ser .mp3)
y correcci´on del nombre (no puede contener otra cosa que valores num´ericos, alfab´eticos
y el gui´on bajo ). Es importante notar que el fichero debe cumplir con unos ciertos
requisitos para poder ser alojado en el servidor, por una serie de motivos que se detallar´an
posteriormente.
Los requisitos que deben cumplir los ficheros para que puedan ser emitidos son:
El tama˜no del fichero debe ser inferior a la cuota fijada (por defecto, 50 MB).
La calidad (bitrate) debe ser igual a 128 Kbps CBR. Esta calidad es equiparable a la
de un CD de audio, por lo que se estima que este bitrate es m´as que suficiente para
que la audici´on sea una experiencia agradable. Es necesario un oido entrenado para
poder distinguir entre esta calidad y un ratio de compresi´on inferior (por ejemplo,
192 o 320Kbps).
El bitrate debe ser constante (CBR); un bitrate variable (VBR) minimiza el espacio
ocupado en disco por el fichero manteniendo la misma calidad de audio, pero puede
ocasionar problemas en el reproductor de audio del oyente (siendo los s´ıntomas m´as
comunes la sensaci´on de “aceleraci´on” del sonido).
La frecuencia (samplerate) debe ser 44100 Hz, lo que repercute en una mayor calidad
del sonido [8].
El nombre del fichero NO puede contener espacios en blanco, ni ninguno de los
siguientes caracteres: (, ), , - y . Esta limitaci´on se impone para facilitar el
manejo de ficheros en el host.
NO debe infringir las leyes de copyrigth y derechos de autor. Esta comprobaci´on
no puede ser efectuada por la herramienta; requiere una persona responsable de los
contenidos, encargada de dar su aprobaci´on a los programas que ser´an emitidos.
En funci´on del tama˜no del fichero a subir, la calidad de la conexi´on del usuario, y el
nivel de tr´afico de la red, llevar´a un mayor o menor tiempo el realizar esta operaci´on.
Para prevenir posibles abusos en el consumo de espacio en disco del host, se ha optado
por restringir la cuota de disco de los usuarios. Para ello, se establece un l´ımite (por
defecto, 200 MB) durante el proceso de instalaci´on, que posteriormente puede ser variado
modificando el valor de la constante MAX CUOTA definida en el fichero de configuraci´on
data.php.
43. CAP´ITULO 4. DESCRIPCI ´ON INFORM ´ATICA 41
El proceso de gesti´on de cuota ocupada en disco se lleva a cabo en el formulario
de subida de ficheros. En la parte inferior de la p´agina, se muestra un contador con la
cantidad de espacio consumido y el restante.
Figura 4.6: Porcentaje de cuota de disco ocupada.
Para estimar la cuota, se hace uso de una serie de comandos de shell de linux (du y
awk); en primer lugar, se calcula la suma de los ficheros de audio alojados en el directorio
asignado a la emisora (por tanto, quedan excluidos ficheros de configuraci´on, listas de
reprodcuci´on y dem´as).
4.7. Servicio web para exportar el cat´alogo la emisora
Uno de los objetivos de esta plataforma es ayudar a sus usuarios en la difusi´on de
sus contenidos. Para facilitar al usuario esta tarea, se ofrece la posibilidad de exportar su
cat´alogo de ficheros, ofreciendo una funcionalidad similar a la gesti´on del cat´alogo de la
plataforma, restringiendo las funciones de borrado, y la modificaci´on de la informaci´on y
visibilidad de los ficheros (entendiendo por visibilidad el hecho de hacer que un fichero
sea descargable o no para el resto de usuarios).
Incluyendo un peque˜no c´odigo PHP y una serie de ficheros requeridos, todos ellos
generados por la aplicaci´on (ver ap´endice D), el usuario dispone en su web de un buscador
sobre su cat´alogo, con funci´on de navegaci´on sobre los resultados de la b´usqueda, que
ofrece la posibilidad de descargar los contenidos. Esta funcionalidad se consigue gracias
al uso de un servicio web.
En el servidor se ha implementado un servicio web (catalogo.ws.php) que usando como
par´ametros un nombre emisora, una palabra empleada como filtro de b´usqueda y un
criterio de ordenaci´on de los resultados, reliza una consulta sobre la base de datos. El
resultado de invocar al m´etodo buscar proporcionado por este servicio es un fichero XML
conteniendo los resultados de la b´usqueda. El cliente del webservice, (mi catalogo.php),
construye una p´agina web a partir de la informaci´on proporcionada, contienendo el
cat´alogo con las funcionalidades previamente enunciadas.
nuSOAP genera autom´aticamente el schema WSDL del servicio, lo que permite obviar
la tediosa tarea de crear manualmente este fichero.
44. CAP´ITULO 4. DESCRIPCI ´ON INFORM ´ATICA 42
Figura 4.7: Mensaje de petici´on SOAP del cliente y respuesta del servicio web.
4.8. Actualizaci´on del fichero de configuraci´on de
Icecast
Para que Icecast pueda difundir el flujo de audio de una emisora, es necesario
especificar un punto de montaje para dicha emisora en el fichero de configuraci´on
/etc/icecast2/icecast.xml. En este punto, surge el siguiente problema: hasta que el servidor
Icecast no se reinicie, las nuevas emisoras no pueden ser o´ıdas puesto que en el fichero de
configuraci´on no consta el punto de montaje de estas.
45. CAP´ITULO 4. DESCRIPCI ´ON INFORM ´ATICA 43
La decisi´on asumida consiste en programar una tarea (usando para ello una entrada
en el cron del sistema) que genere el nuevo fichero de configuraci´on de Icecast (realizado
por el script config icecast.php). A partir de la informaci´on contenida en la base de datos
de la emisora, obtener los datos de los nuevos puntos de montaje es trivial.
Una vez generado el nuevo fichero de configuraci´on, se procede a reiniciar el proceso
del servidor Icecast. Al realizar esta operaci´on, todos los posibles oyentes conectados al
servidor de streaming sufren una desconexi´on temporal, que ser´a restaurada en el momento
en que Icecast opera nuevamente.
Para minimizar el n´umero de reinicios del servidor Icecast (y por tanto, las molestias
que ocasionan a los oyentes), se ha tomado la decisi´on de reiniciar el servidor una s´ola
vez al d´ıa, en horario de madrugada. Este problema se puede solventar incluyendo en un
futuro un servidor de respaldo que contin´ue difundiendo las emisiones actuales mientras
se produce el reinicio del servidor “principal” de Icecast. Otra opci´on es deshabilitar el
reinicio programado del servidor, pol´ıtica aplicable s´olo en el caso de saber con certeza
que no se requiere la creaci´on de nuevas emisoras.
La pol´ıtica de establecer un ´unico reinicio diario de Icecast provoca que hasta que ´este
no se lleve a cabo, las nuevas emisoras de audio no puedan estar operativas.
4.9. Creaci´on del fichero XML para el servicio de
podcast
El podcasting consiste en la distribuci´on de los contenidos a partir de un fichero XML.
Dicho fichero contiene la informaci´on referida a los contenidos, de forma que ´esta pueda
ser gestionada por diversos programas, siendo el m´as popular el iTunes de Apple.
Para la generaci´on del XML de una emisora, basta con tomar la informaci´on contenida
en la tabla Contenidos de la base de datos (tarea de la que se encarga el scrip
generar rss.php, ejecutado cada vez que se produce un cambio en la tabla de contenidos).
S´olo se publican aquellos ficheros cuya descarga permita expl´ıcitamente el “due˜no” de la
emisora.
El XML generado tiene la estructura descrita en la siguiente plantilla:
<?xml version=‘‘1.0’’ encoding=‘‘iso-8859-1’’?>
<rss version=‘‘2.0’’ xmlns:content=‘‘http://purl.org/rss/1.0/modules/content/’’
xmlns:wfw=‘‘http://wellformedweb.org/CommentAPI/’’
xmlns:dc=‘‘http://purl.org/dc/elements/1.1/’’
xmlns:itunes=‘‘http://www.itunes.com/dtds/podcast-1.0.dtd’’>
<!--
Las etiquetas ‘‘itunes’’ son espec´ıficas para el programa itunes.
La informaci´on b´asica y esencial se define en las etiquetas que NO son de itunes.
Es recomendable rellenar toda la informaci´on, inclusive la itunes
46. CAP´ITULO 4. DESCRIPCI ´ON INFORM ´ATICA 44
-->
<channel>
<!-- Datos generales del podcast, que s´olo tendr´as que escribir una vez -->
<title>TITULO DEL PODCAST</title>
<link>Enlace a la web que contiene el podcast</link>
<description>Breve descripci´on del podcast</description>
<itunes:summary>Breve descripci´on del podcast</itunes:summary>
<language>Idioma del podcast, en formato ‘‘idioma-PAIS’’</language>
<!-- datos del autor -->
<itunes:author>Nombre del autor</itunes:author>
<itunes:owner>
<itunes:name>Nombre del autor</itunes:name>
<itunes:email>Email del autor</itunes:email>
</itunes:owner>
<!-- logotipo del podcast -->
<image>
<url>URL de la imagen</url>
<title>T´ıtulo del podcast</title>
<link>Enlace a la web</link>
</image>
<itunes:image href=‘‘url de la imagen’’/>
<itunes:category text=‘‘International’’>
<itunes:category text=‘‘Spanish’’/>
</itunes:category>
<itunes:category text=‘‘Technology’’>
<itunes:category text=‘‘Information Technology’’/>
<itunes:category text=‘‘Computers’’/>
</itunes:category>
<!-- item se repite una vez por cada fichero de audio distinto -->
<item>
<title>t´ıtulo del contenido</title>
<link>Direcci´on de la p´agina web del contenido</link>
<description>Descipci´on del contenido</description>
<enclosure url=‘‘URL del fichero de audio’’ length=‘‘tama~no en bytes del fichero’’
type=‘‘audio/mpeg’’/>
<pubDate>Mon, 22 May 2006 16:00:00 +0100</pubDate>
</item>
</channel>
</rss>
47. Cap´ıtulo 5
Conlusiones y l´ıneas futuras
A continuaci´on se exponen las conclusiones y futuras l´ıneas de trabajo que se puedan
derivar de este proyecto.
5.1. Conclusiones del proyecto
Este proyecto se inici´o sin tener claramente definido el objetivo final del mismo.
El resultado expuesto es la evoluci´on de los sucesivos objetivos fijados en las sucesivas
reuniones de las personas implicadas en este proyecto (Grupo de Audiovisuales y Redes
Multimedia, alumnos de la asociaci´on de radio y profesores del ´area de Ciencias de la
Comunicaci´on).
Partiendo de cero (el alumno desconoc´ıa la mayor´ıa de los conceptos manejados, el
lenguaje de programaci´on PHP, y no hay trabajos previos en la facultad que versen sobre
esta tem´atica que pudieran servir de referencia), se ha obtenido una plataforma innovadora
que cumple con las expectativas marcadas.
La aplicaci´on hace uso de la mayor´ıa de tecnolog´ıas en boga (servicios web, PHP,
AJAX, podcast, streaming), lo que me ha permitido adquirir unos conocimientos
adicionales de suma utilidad; tanto es as´ı que mi actual trabajo est´a estrechamente
relacionado con la experiencia adquirida durante la colaboraci´on con el Grupo de
Audiovisuales.
A expensas de solucionar los problemas relacionados con la aprobaci´on de los
contenidos a emitir, se espera que durante el pr´oximo curso se proceda a utilizar la
plataforma de radio.
5.2. L´ıneas futuras
Este proyecto, de caracter´ısticas innovadoras (no se tiene constancia de trabajos
previos relacionados con los sistemas de radio sobre IP en la Universidad Rey Juan Carlos),
asienta las bases sobre las que desarrollar futuras mejoras o nuevos proyectos.
Entre las futuras l´ıneas, se pueden destacar las siguientes:
45
48. CAP´ITULO 5. CONLUSIONES Y L´INEAS FUTURAS 46
Difusi´on de contenidos de v´ıdeo: esta plataforma puede servir de base para la
distribuci´on de contenidos de video, realizando una serie de cambios en el back-end
de la aplicaci´on.
Realizar la autenticaci´on de usuarios a trav´es de LDAP: en la actualidad, el sistema
usa un sistema propio para la gesti´on de usuarios; es una buena idea hacer uso del
servicio de LDAP de la Universidad para la autenticaci´on del usuario.
Crear una parrilla de programaci´on de una emisora que se ejecute en el tiempo: en
la actualidad, la pol´ıtica de reproducci´on es un bucle de ficheros en orden secuencial;
una buena idea ser´ıa permitir el que en una determinada hora y d´ıa, se emita un
determinado programa.
Habilitar un mecanismo para la transmisi´on de programas en directo.
Portar la plataforma a otros sistemas operativos: la plataforma ha sido desarrollada
para sistemas Linux, ya que ofrecen una gran facilidad para gestionar los procesos
de la m´aquina. Modificando la parte de la aplicaci´on relacionada con la gesti´on de
procesos, la plataforma podr´ıa funcionar en otros sistemas operativos.
Habilitar un mecanismo de servidores de respaldo para evitar el tener que reiniciar
el servidor para que las nuevas emisoras puedan entrar en funcionamiento.
Permitir la configuraci´on de los par´ametros del servidor Icecast v´ıa web, ya que
actualmente, s´olo es posible modificar el fichero de configuraci´on de Icecast a trav´es
de un script ejecutado en una tarea programada.
Permitir compartir contenidos entre distintas emisoras.
49. Bibliograf´ıa
[1] R.Fielding, UC Irvine, J.Gettys, J.Mogul, DEC, H.Frystyk, T.Berners-Lee, MIT/LCS.
Request For Comments: 2068. Hypertext Transfer Protocol HTTP/1.1. Network
Working Group. Enero de 1997.
[2] Kent Beck, Extreme Programming Explained: Embrace Change. Addison Wesley
Professional. Octubre de 1999.
[3] P´agina oficial del lenguaje de programaci´on PHP: http://php.net
[4] P´agina oficial del est´andar ID3: http://www.id3.org
[5] P´agina oficial del proyecto getID3(): http://getid3.sourceforge.net/
[6] P´agina oficial del proyecto nuSOAP: http://sourceforge.net/projects/nusoap/
[7] Miguel A. Ar´evalo, Art´ıculo sobre la reutilizaci´on del software titulado “No reinventar
la rueda”: http://marevalo.net/creacion/unmundofeliz/mundofeliz3.html
[8] Art´ıculo sobre la relaci´on entre la calidad de audio y la frecuencia :
http://mural.uv.es/samecues/audio.htm
47
50. Ap´endice A
Instalaci´on del Software
En esta gu´ıa se detallan los pasos a seguir para la instalaci´on de las aplicaciones
requeridas en una m´aquina con el sistema operativo Ubuntu Breezy (5.10), una derivaci´on
de la distribuci´on Debian. En otras distribuciones de linux (en particular, RedHat y SuSe),
los pasos pueden diferir ligeramente.
A.1. Actualizaci´on de la lista de repositorios.
NOTA: para ejecutar los comandos de los siguientes pasos, es necesario hacerlo como
el usuario root. En Ubuntu, basta con ejecutar
sudo su
, y a continuaci´on, solicitar´a la contrase˜na del usuario con el que se inici´o la sesi´on.
Se debe actualizar la lista de repositorio (fichero /etc/apt/sources.list ), a˜nadiendo los
repositorios universe. Basta con descomentar (borrar el s´ımbolo #) las siguientes l´ıneas:
deb http://es.archive.ubuntu.com/ubuntu breezy universe
deb-src http://es.archive.ubuntu.com/ubuntu breezy universe
NOTA: No es aconsejable mezclar repositorios de distintas versiones de Ubuntu (por
ejemplo, de Breezy y Dapper, versiones 5.10 y 6.06 de Ubuntu, respectivamente), ya que
puede provocar efectos tales como que no se desconfigure (y por tanto, no se inicie) el
servidor gr´afico, que los enlaces de los men´us del sistema desaparezcan o apunten a otros
recursos, que no se inicien ciertas aplicaciones, etc.
Una vez incluidas las ubicaciones de los repositorios, se debe actualizar la cach´e de
ficheros contenidos en los repositorios. Para ello, hay que ejecutar el comando siguiente:
apt-get update
48
