A New Under-sampling Approach

Figura 3.2: Ubicación geográfica del Data_Center de la Universidad

El ISP cuenta con una base de datos donde se guarda la información; que permite manejar los datos de forma organizada y acceder adecuadamente a estos, para ser utilizados según la necesidad del proveedor de servicios. La base de datos almacena los detalles referentes a las características de la señal de televisión recibida, los modelos de los STBs con que cuentan los hogares, la ubicación geográfica de los mismos, la información del canal visualizado y la hora en que ocurre la retroalimentación para luego poder conocer las especificaciones acerca de aplicaciones interactivas, servicios y eventos escogidos por el usuario.

3.2 Implementación del esquema cliente-servidor

En la aplicación el programa en el cliente envía los datos de las características de la señal recibida, la preferencia de los usuarios, entre otras estadísticas, al servidor. Mientras que,el programa en el servidor permanece pasivo escuchando hasta que llegue información proveniente del usuario de DTV; cuando se recibe la información se guarda de forma organizada en la base de datos, con el fin de que estos puedan ser utilizados posteriormente.

3.2.1 Cliente

El programa cliente inicia la comunicación con el servidor y le envía la información. La Figura 3.3 presenta un fragmento del código para el cliente, donde la operación de la biblioteca socket, send() es la encargada de realizar el envío . En este se utilizan los sockets para intercambiar los flujos de datos (bytes) por la red de manera fiable. Un socket es un descriptor de archivo destinado a mover bytes por una red permitiendo conectar ordenadores remotos. Las propiedades de un socket dependen de las características del protocolo en el que se implementan. Como se ha menciona en el epígrafe 2.1 la pila de protocolos ocupado para el esquema de transmisión propuesto es TCP/IP. En la programación del modelo cliente- servidor TCP/IP se pueden utilizar dos tipos de sockets:

 Sockets de flujo (TCP).

 Sockets de datagramas (UDP).

Para este programa se emplea el protocolo, más utilizado a nivel global, TCP (sockets de flujo) como se ve en la segunda línea de código de la Figura 3.3; donde se fija AF_INET para el dominio de direcciones y se define el socket de flujo, tipo SOCK_STREAM. Cuando se implementan con el protocolo TCP, los sockets tienen las propiedades de ser orientado a la conexión, proteger la transmisión de todos los octetos sin errores ni omisiones y garantizar que todo octeto llegue a su destino en el mismo orden en que se ha enviado (existe corrección de errores y retransmisión). Además para evitar errores cuando se necesite volver a enviar la información se cierra el socket cuando se termina de transmitir los datos, liberando el socket y denegando cualquier envío o recepción a través del mismo, en la última línea del código la Figura 3.3 con la operación estándar close().

La información a enviar por el STB denominada como la variable message, de acuerdo a la estructura establecida en el epígrafe 2.6 para la transmisión, queda especificada en la función definida en la Figura 3.4. Para emular los datos que debe enviar el STB se ha decidido que los caracteres que componen los campos de la estructura sean entrados de forma manual en el momento de las pruebas; para reproducir el comportamiento real tanto del usuario como de la señal televisiva. Excepto el campo Hora, en el cual se extrae la hora exacta en el momento del envió directamente del sistema operativo del cliente, utilizando la función datetime.now(); este proceso es el que se seguirá en el ambiente real de la interactividad.

Figura 3.4: Sección del programa para el STB cliente. Estructura de datos a enviar

Para la transmisión periódica que se determina en el epígrafe 2.1 se crea la función time_env() expuesta en la Figura 3.5, correspondiente a un sector del programa cliente. Esta función es un método, tomado como ejemplo, para demostrar que es viable la trasferencia periódica en los horarios establecidos por el proveedor de servicios de acuerdo a lo planteado en el Caso de Estudio 2 (epígrafe 2.3). Sin embargo, cuando el software de la Raspberry como STB cuente con un mayor nivel de complejidad y con varias aplicaciones solicitando el mando sería interesante utilizar la biblioteca Celery, la cual se encargaría de las cuestiones referentes al tratamiento del envío periódico de los datos.

Figura 3.5: Fragmento del programa para el STB cliente. Función para el envío periódico.

3.2.2 Servidor

El primer paso en el programa para el servidor, al igual que en el cliente es la creación del socket para recibir los datos enviados por el usuario como se muestra en la Figura 3.6 de la función recibe_data(). Debido a que puede llegar información de distintos usuarios por el mismo puerto, se necesita reutilizarlo para evitar errores y pérdidas de datos; esto se maneja mediante la operación setsockopt(). Luego para atender a la conexión se hace uso de la operación listen() y para liberar el socket, después de aceptar los datos que componen la estructura para retroalimentación, se emplea la operación close() como se observa en la última línea de código de la Figura 3.6.

Básicamente el programa del servidor se encarga de recibir la información de la Raspberry y proceder a almacenar la estructura recibida en la base de datos; para obtener resultados cuantificables que puedan ser posteriormente analizados. Este proceso de guardar la información en la tabla DataDTV de la base de datos server_dtmb diseñada, se evidencia en las líneas de código de la función base_data() en la Figura 3.7. El sistema gestor de bases de datos que se ocupa es MySQL debido a la licencia Open Source, la seguridad y bajo consumo de recursos que ofrece en su ejecución.

Figura 3.7: Fragmento del código para el servidor. Función para guardar la información en la base de datos.