4.5 Obtención de datos específicos de Slate-1.1
El alto costo que tiene el servicio del servicio de internet para una empresa tan grande como lo es el CICESE (Centro de Investigación Científica y Educación Superior de Ensenada), el incremento de el tráfico hacia el internet en la red hizo que se tuviera la necesidad de llevar un control de quien accesa a internet, verificar que este dando un correcto uso de este servicio. Es en este punto donde se vieron las ventajas que ofrece la gestión de contabilidad, y se puso en marcha un análisis para encontrar la solución mas factible para la implementación de este. Actualmente trafico dirigido al internet del CICESE esta controlado por un enrutador principal (Cabletron Smart Switch Router 8000), que provee enrutamiento de la red interna del CICESE y las conexiones remotas (módems por medio de CICESE) hacia el internet o internet 2. Las características que nos ayudará a lograr nuestro objetivo es el soporte del protocolo LFAP, el cual viene implementado por hardware en el enrutador.
Además de la ventaja que proporciona que la gestión de contabilidad ya esta implementada por el enroutador, esta el hecho de que ya existe actualmente un programa que implementa el protocolo LFAP y logra comunicarse con el enrutador obteniendo así la información que este gestiona. La desventaja que este tiene es que solo obtiene los datos que el enrutador le envía, mas no lleva una contabilidad sobre cuanto trafico consume determinado usuario de la red. El programa original muestra en pantalla los flujos generados en el CCE del enrutador.
Los tipos de flujo mostrados son los FAR (Flujo nuevo creado al transmitir o recibir información a través del enrutador de gestión) y FUN (Actualización de la información del flujo anteriormente creado). Además de mostrar mensajes de error cuando falla la transacción del protocolo.
El sistema que se desea implementar será basado en el programa existente (slate) para la comunicación por medio del protocolo LFAP desde el FAS (Flow Accounting Server) hacia el CCE (Call Control Entity). El programa planteado usara la información presentada por “slate”, dándole formato para ser almacenada de alguna manera para ser revisada por medio de una página web. Dicha página debe de mostrar reportes de volumen consumido por dirección IP registrada en la red.
Para realizar un buen sistema de gestión, es importante seguir una metodología de desarrollo. Para esta investigación, se utilizaron técnicas usadas en la ingeniería de software, las cuales nos brindan variadas herramientas par una mejor comprensión de lo que se está haciendo.
Las técnicas usadas para la realización de este proyecto fueron variadas y no se siguió ninguna secuencia establecida por alguna metodología en específico.
La metodología que se utilizo esta basada principalmente en 4 etapas: análisis, diseño y desarrollo, donde esta ultima abarca las fases de programación (codificación) y pruebas. Cada una de estas etapas tiene una meta propia, y a su vez comprende tareas específicas, las cuales se describen en los siguientes puntos.
Etapa del análisis del sistema: Consiste en recabar la información necesaria para poder entender lo mayor posible los requerimientos, alcances y limitaciones del sistema de cómputo a desarrollar. En esta etapa se definieron las características del sistema de gestión de contabilidad que se desea implementar en CICESE, done se toman en cuenta el hecho de que ya existía un programa que obtenía la información necesaria para llevar a cabo la contabilidad. Lo que se hizo necesario fue definir los campos que se deseaban tomar en cuenta para contabilizar, siendo por el momento los campos de: IP (IP perteneciente a la red del CICESE), Bytes Transmitidos, Bytes Recibidos. El programa esta codificado en C, con instrucciones para el sistema operativo Windows de Microsoft y también para Linux C. Debido a la facilidad que proporciona el lenguaje C de linux se eligió este como la plataforma de trabajo. Otra de las necesidades que hubo que analizar fue la interacción del programa para obtener la información requerida y mantener un registro de esta para futuras consultas. Para solucionar esta incógnita se opto por la modificación del programa que obtiene la información sobre el tráfico en la red para enviar la información deseada a una base de datos de la cual se pudiera consultar posteriormente por medio de una página web.
Etapa del diseño del sistema: En esta etapa se representa gráficamente el flujo de información que debe existir dentro del sistema así como los módulos que comprende y su funcionamiento interno. Una vez definidos los requerimientos y lo que se desea obtener de este sistema, se deben tomar las medidas necesarias para cumplir con cada uno de los objetivos. Para ello se debe diseñar lo mejor posible cada una de las partes que lo compondrán. En esta etapa la planeación y diseño basado en módulos o funciones separadas fue requerida, ya que da una solución más fiable, dando la posibilidad de actualizaciones o correcciones futuras del programa de una manera más fácil.
Etapa de Desarrollo: La idea fundamental de esta etapa consiste en materializar el análisis y diseño que se realizo en las etapas anteriores con la realización de un sistema de computo (programa) que plasme los objetivos trazados para la realización del mismo. Llegada esta etapa, teniendo un buen diseño de lo que será el programa, tan solo se codifica en el lenguaje deseado. En este caso el lenguaje de programación fue C con implementaciones de librerías de mysql para manejo de base de datos.
Mysql C API o Aplicación de Mysql para lenguaje C, es el código de una distribución de mysql que se este manejando actualmente incluida en la librería mysqlclient y permite a programas hechos en C accesar a bases de datos.
4.5 Obtención de datos específicos de Slate-1.1
Como ya se menciono en el capitulo anterior, slate es un programa que decodifica la información enviada por el CCE (Entidad de Llamadas de Control). Arrojando la información de la manera siguiente. Cabe mencionar que en la siguiente explicación no se muestra toda la información que un mensaje FAR o FUN otorga debido a que no se utilizo en este programa.
Para mensajes FAR:
F:1.2.2985, 65.65.81.16, 158.97.39.251
Para mensajes FUN:
U:1.2.2985, 382 bytes active
Donde por medio de un algoritmo de programación, del mensaje FAR que esta compuesto de el ID del flujo, IP origen e IP destino (en ese orden respectivamente). Se verifica cual de los dos IP’s es el que pertenece a la red del CICESE, detectando de esta manera si el IP del CICESE es el origen o el destino. Esto con el propósito de saber si este IP esta transmitiendo o recibiendo información a través de internet.
Si el IP que buscamos se encuentra en la sección de “IP origen”, esto nos indica que es el que origina el trafico de datos por consiguiente esta transmitiendo. Para el caso contrario, si es el “IP destino”, sabemos que esta recibiendo datos.
En el siguiente flujo (FUN) se muestra el ID del flujo, la cantidad de bytes que ocurrieron en ese flujo y el estado del flujo a la hora que este ocurre. El ID del flujo fue creado anteriormente por el mensaje FAR. Asociando ese ID del flujo con el creado en el mensaje FAR, sabemos a quien pertenece y si estaba transmitiendo o recibiendo datos. Por lo que al recibir un mensaje FUN para ese flujo, este nos indica que cantidad de bytes fueron enviados o recibidos (esto lo calculamos previamente) fueron transmitidos, además de saber si ese flujo aun sigue activo. Esto quiere decir que pueden existir mas mensajes FUN dando más información, y no es hasta que se recibe un mensaje FUN con el estado de inactivo cuando se sabe que ya no abra más información para ese flujo.
Para lograr recordar a que IP pertenece el ID del flujo que nos indicó el mensaje FAR, fue aquí donde se utilizó una base de datos que nos auxiliara. Se 2 manejaron tablas, una para contener la asociación de identificadores de flujo (DI) y números de IP. Y otra tabla con la información de bytes enviados y recibidos por cada IP. Las tablas contienen los siguientes campos.
Figura 4.1 Descripción de la tabla de FAR’s
Donde el campo ‘id’ se utiliza para contener el identificador de flujo generado por el CCE. El campo ‘ip’ conteniendo la dirección IP perteneciente al CICESE asociado un determinado flujo. El campo ‘mode’ indicando el modo calculado para ese flujo (transmitiendo o recibiendo). Una vez teniendo una tabla con las relaciones entre ID, IP y MODE, se utilizo otra tabla para contener la información final para cada IP. Quedando de la siguiente manera.
Figura 4.2 Descripción de la tabla principal.
Donde el campo ‘ip’ es el IP local de CICESE, ’b_rx’ es la cantidad en bytes de datos transmitidos para el ‘ip’ asociado y ‘b_tx’ es la cantidad de bytes transmitidos por este mismo ‘ip’. Cada vez que ocurra un mensaje FUN conteniendo una actualización de los bytes para un IP determinado, se suma al previamente contenido en esta tabla. Quedando de esta manera un sistema que almacena una relación de IP, Bytes transmitidos y Bytes recibidos. Que es el objetivo principal de este sistema.