INSTITUTO POLITECNICO NACIONAL

CENTRO DE INVESTIGACION EN COMPUTACION LABORATORIO DE MICROTECNOLOGIA Y SISTEMAS EMBEBIDOS

INTEGRACIÓN DE UNA RED DE TRANSMISIÓN DE DATOS A TRAVÉS DE MÚLTIPLES SUBREDES

ELÉCTRICAS

Reporte Técnico Final

Numero del Proyecto: 20080532

Vigencia del Proyecto: Febrero- Diciembre 2008

Líder del Proyecto: Dr. Luis Alfonso Villa Vargas

Participantes: Romeo Urbieta Parrazales

Marco Antonio Ramírez Salinas

José Luis Oropeza Rodríguez

Oscar Camacho Nieto

Titulo del documento: Reporte Técnico Final

Fecha: Enero 30, 2009

Versión: 1.0

Nombre del archivo: SIP2008_Reporte_Final.doc

COPYRIGHT

© Copyright 2001, Instituto Politécnico Nacional (IPN),

© Centro de Investigación en Computación (CIC)

© Laboratorio de Microtecnología y Sistemas Embebidos (MICROSE-LAB)

This document may not be copied, reproduced, or modified in whole or in part for any

purpose without written permission from the IPN-CIC. In addition to such written

permission to copy, reproduce, or modify this document in whole or part, an

acknowledgement of the authors of the document and all applicable portions of the

copyright notice must be clearly referenced.

All rights reserved.

This document may change without notice.

RESUMEN

En este reporte se da una explican de manera general sobre avances del proyecto PIFI denominado:“INTEGRACIÓN DE UNA RED DE TRANSMISIÓN DE DATOS A

TRAVÉS DE MÚLTIPLES SUBREDES ELÉCTRICAS” que se desarrollo durante el año 2008.

El sistema WEB de este proyecto a la fecha esta constituido por los siguientes elementos:

■ Módulos de programación desarrollados en .Net (C#).

■ Una Base de Datos diseñada en Oracle

■ Un conjunto de dispositivos electrónicos (dispositivos PLC que permiten la transferencia de la información bajo el contexto de la red eléctrica).

Cabe mencionar que las principales funcionalidades que se han logrado son: Integridad y consistencia de los datos almacenados en la base de datos, manipulación de información a través de la aplicación WEB, y transferencia de audio, video y datos; todas estas pruebas, utilizando el contexto de la red eléctrica para de esta manera ofrecer un Servicio WEB enfocado a la Educación (Clases Virtuales).

Se han obtenido buenos resultados hasta hoy, en este reporte se dará a conocer un panorama mas amplio del sistema, así como la secuencia de etapas que se han llevado a cabo para el desarrollo del mismo.

INTRODUCCIÓN

El proyecto consiste en una Base de Datos diseñada bajo el Sistema Gestor de Bases de Datos Oracle 11g. Dicha Base de Datos contiene información de escuelas del Instituto Politécnico Nacional, Profesores, Alumnos, y los Cursos que se imparten en las distintas escuelas del y que estén enlazados a nuestro sistema WEB.

La información que se tiene almacenada en la Base de Datos es un banco de datos que en conjunto con la plataforma WEB ofrecen el servicio WEB orientado a la educación y que ofrecerá clases virtuales a los usuarios.

La Base de Datos se comunica con una plataforma WEB desarrollada en tecnología .Net (Servicio WEB) a través de un conector OracleConnection y una cadena de conexión que especifica los parámetros necesarios para establecer la comunicación entre estas dos tecnologías. (por ejemplo: base de datos, usuario, contraseña, etc.).

Dentro del código desarrollado para la plataforma WEB se han incluido consultas personalizadas que nos permiten obtener datos enriquecidos desde la Base de Datos, los cuales son útiles para el usuario administrador, también se han incluido algunas otras consultas más simples cuya función es: visualizar, seleccionar, insertar o modificar cierta información contenida en la Base de Datos, tales tareas pueden ser ejecutadas por usuarios finales y usuarios administrador con la diferencia que los primeros están limitados a modificar ciertos datos almacenados en la Base de Datos, es decir, en algunos casos se requiere ser administrador del sistema para poder modificar ciertos datos.

El esquema conceptual de la Base de Datos esta constituida por un total de 8 entidades normalizadas hasta la tercera forma normal de Boyce-Codd bajo el contexto del Modelo Relacional para Bases de Datos y con la capacidad de expansión si es necesario. Por otra parte, la cantidad de código referente a la plataforma WEB que se ha programado (conector, cadenas de conexión, consultas, interfaz gráfica, etc.) comprenden aproximadamente 500 líneas.

Con las características mencionadas anteriormente tanto de la Base de Datos como de la plataforma WEB, se logró cargar, modificar y borrar registros de: Escuelas, Profesores, Alumnos y Cursos, así como también se logró transferir información de tipo audio, video y/o datos bajo el contexto de la red eléctrica, utilizando tecnología PLC (Comunicaciones por líneas de Potencia).

Se realizaron pruebas piloto del sistema y se obtuvieron resultados satisfactorios durante la transferencia de la información, una primer prueba se llevó a cabo bajo la subred eléctrica del Auditorio Jaime Torres Bodet (2008) y como resultado, la integridad de la información en la Base de Datos durante las pruebas se mantuvo al 100% al igual que durante la transferencia de la misma al ser manipulada usando la plataforma WEB.

La segunda prueba fue realizada......obteniéndose resultados muy satisfactorios, demostrtando la madures de la tecnología PLC tambien para subredes eléctricas.

1 OBJETIVO GENERAL .

Gestionar una Base de Datos para evaluar la transferencia, integridad y consistencia de la información trasmitida a través de dos subredes eléctricas equipadas con tecnología PLC, así como evaluar el manejo confiable y seguro de la información generada y/o manipulada a través del Servicio y la interfaz WEB.

2 OBJETIVOS ESPECÍFICOS.

� Equipar dos subredes eléctricas del Centro de Investigación en Computación con tecnología PLC (Power Line Comunications)

� Pruebas de monitoreo utilizando las dos subredes eléctricas con tecnología PLC.

� Programación de la interfaz y el Servicio WEB para la Educación � Pruebas y carga de la información a la Base de Datos utilizando el Servicio

y la interfaz WEB. � Implementación del sistema utilizando la red eléctrica y dispositivos PLC

como medio de comunicación. � Pruebas y resultados obtenidos.

3 ESQUEMA GENERAL DEL PROYECTO.

Figura 1.- Diseño General del Sistema

El diseño general del sistema se muestra a continuación [Figura 1], en la figura podemos ver la relación que existe entre la Base de Datos y el Servicio e interfaz WEB. Una vez que se finalice el proyecto y se implemente al 100% bajo la tecnología PLC, se pretende ofrecer un Servicio WEB enfocado a la educación (clases virtuales impartidas en el Instituto Politécnico Nacional) a localidades rurales lejanas carentes de tecnología digital; así como también, se pretende implementar otros servicios WEB como Salud, Laboratorios y Bibliotecas Virtuales entre otros.

4 DESARROLLO DEL PROYECTO.

DISEÑO Y ESTRUCTURA DE LA BASE DE DATOS.

Figura 2.- Esquema Relacional de la Base de Datos.

La Base de Datos fue diseñada en Oracle 11g y se utilizo el Modelo Relacional para definir la estructura y funcionamiento. Esta compuesta por 8 tablas o entidades normalizadas hasta la tercer forma normal de Boyce-Codd y cada tabla almacena información específica utilizada por el Servicio WEB Educación. La siguiente figura [Figura 2] muestra el esquema general.

Cada una de las tablas mostradas en la Figura 2, almacena información específica de Escuelas, Profesores, Alumnos, Cursos, etc..

5 DESARROLLO DEL SERVICIO E INTERFAZ WEB.

Se programó un Servicio WEB llamado “Educación” en el lenguaje de programación C# y se diseño la interfaz que permite la ínter operabilidad con la Base de Datos para recuperar, modificar, insertar y borrar información, cabe mencionar que se crearon dos módulos: uno para los usuarios finales y otro para el administrador del sistema.

Algunos de los elementos que componen la interfaz de usuario final son:

� Registro de Usuarios. � Registro a Cursos. � Inscripción a Cursos. � Enlace a la transmisión de clases en tiempo real (audio y video) � Modificación de Información personal.

Mientras que los componentes principales de la interfaz administrativa realiza las siguientes tareas hasta el momento:

� Registro de Escuelas, Profesores y Cursos. � Modificación de la información de: Escuelas, Profesores y Cursos. � Eliminación de:Escuelas, Profesores y Cursos. � Consultas enriquecidas para el análisis de productividad como:

profesores y cursos mas demandados, usuarios registrados por área de conocimiento y/o por nivel de conocimiento, escuelas mas demandadas, usuarios que a mas cursos se han inscrito, otras.

6 PRUEBAS

a) INTERFACES DE USUARIO.

i) INTERFAZ PRINCIPAL DEL USUARIO.

Es aquí donde un usuario puede firmarse o registrarse en el sistema para que posteriormente pueda hacer uso del mismo ya que si no es un usuario registrado, no podrá utilizar el sistema. [Figura 25].

Figura 25.- Muestra la Interfaz principal del Usuar io

ii) INTERFAZ DE TRANSMISIÓN DE VOZ Y DATOS.

Esta interfaz nos permite seleccionar y visualizar un curso en línea para ello, se debe: hacer la del nivel de educación al que pertenece el curso que deseamos

tomar, enseguida se selecciona el área a la que pertenece dicho curso, seleccionamos después la escuela donde se esta impartiendo y por último seleccionando el curso, profesor y horario en el que se quiere tomar. Si el curso se esta transmitiendo en línea, aparece la pantalla con la transmisión como se muestra a continuación en la figura.

INTERFAZ DE ADMINISTRADOR.

Para la gestión de la Base de Datos como administrador se han programado scripts que nos permiten recuperar información especifica importante desde la base de datos. Algunas pruebas son las siguientes:

iii) P RUEBAS DE ADMINISTRADOR.

Se han realizado pruebas para evaluar la integridad de los datos durante el uso y almacenamiento de la información utilizando la plataforma WEB, la Base de Datos y el contexto de red eléctrica en conjunto. Este tipo de consultas nos permiten extraer información importante del sistema, los usuarios, profesores y/o escuelas.Tecnologías a utilizadas.

i) SOFTWARE.

� Sistema Gestor de Bases de datos Oracle 11g Enterprise. � Visual Studio .Net 2005(Lenguaje de programación C#). � Sistema Operativo Windows XP profesional SP2. � Servidor ISS Versión 5.1 de Windows. � Dezing DataBases.

ii) HARDWARE .

� 2 Computadoras portátil procesador 2.2 GHz, 2 GB en RAM y 80 GB en disco duro.

� Equipo PLC comercial Corinex con velocidad de transferencia de 10/100 Mbps

� Cámara WEB FIRE-i.

RESULTADOS .

Se han realizado pruebas físicas de la implementación del sistema bajo el contexto de la red eléctrica obteniéndose resultados muy satisfactorios, ya que la información que circula entre el cliente y el servidor no sufrió ninguna alteración y su almacenamiento en la base de datos en todo momento fue correcto.

Una primer prueba consistió en realizar la transmisión de video y datos a través del sistema, simulando una clase presencial que se transmitía vía Internet, con esta prueba nos percatamos que había una perfecta transmisión de video y datos, verificando así que el sistema no presentaba ningún problema de transferencia de la información en cuanto a la aplicación y a la base de datos, aún cuando la comunicación se realizaba por la red eléctrica, siendo además corriente y voltaje no regulado. La transmisión de estas pruebas, se realizaron con la aplicación ya mencionada.

Nota: La transmisión de video genera un retardo de 8 segundos, esto debido al equipo PLC y no a alguna falla del sistema, ya que se transmitía a una velocidad de 10Mb por segundo siendo esta una de las posibles razones del retraso que presentaba la transmisión de video.

7 CONCLUSIONES.

Durante el desarrollo de este proyecto me he dado cuenta que se tienen grandes oportunidades de éxito, ya que al parecer la comunicación atreves de PLC a arrojado buenos resultados.

Por otra parte se tiene que seguir trabajando con los servicios web, ya que aún se pueden implementar muchos elementos que beneficiarían al sistema como lo son: services transaccions, agentes inteligentes de software, entre otros.

Se ha sobrepasado las expectativas en cuanto al tabú de la transmisión de información atreves de la tecnología PLC, también con ello la funcionalidad del sistema, la cual no presento ningún inconveniente o falla alguna.

El dinamismo, potencia y factibilidad que nos ofrecen los servicios web me hacen pensar que se pueden llegar a realizar grandes cosas con ellos, ya que gracias a estos se puede dotar al sistema con infinidad de herramientas y servicios primarios los cuales carecen comunidades que se encuentran ubicadas en la última milla, así se podrá brindarles un mejor panorama de vida. Con un gran esfuerzo y dedicación se puede lograr que las personas de estas comunidades puedan estudiar, tengan atención médica y sobre todo conocimiento, que es necesario para la sobrevivencia dentro de este país en el cual es necesario una formación académica para lograr un mejor futuro.

Por último es necesario hacer énfasis en que no se presentan ningún tipo de problemas a resolver en la comunicación vía PLC por tal motivo se ha determinado realizar un cambio en el rumbo del proyecto. Ahora se pretender crear un sistema capaz de distribuir el trabajo sobre un Desktop Grid Computing para evitar que la conexión de múltiples usuarios simultáneos pueda ocasionar diversos problemas.

Problemas como colapsos debido a la extenuación de recursos (memoria, disco duro, CPU). Generación de cuellos de botella, agotamiento del ancho de banda, entre otros.

Desarrollo de un Sistema Grid Computing para la Distribución de Servicios Utilizando Plataformas PLC

1. Introducción

Comúnmente es necesario realizar pruebas o simulaciones de circuitos electrónicos para que ciertos usuarios puedan observar el funcionamiento de sus circuitos electrónicos que han creado de manera virtual; pero que aun no saben si en verdad funcionarán de acuerdo a sus necesidades, de tal manera es imposible para ellos llevar a un estado físico tales circuitos hasta que no realicen todo el conjunto de pruebas necesario para verificar que el funcionamiento de dichos circuitos será el adecuado. Algunas veces estas pruebas se vuelven demasiado tediosas o casi imposibles de realizar ya que requieren de un gran tiempo para realizarlas y frecuentemente hasta de diversos grupos de trabajo para realizarlas, generando además de ello problemas que impiden realizar eficazmente un conjunto de pruebas necesarias que sustenten el buen funcionamiento de los circuitos.

Como una alternativa para realizar ese conjunto de pruebas se tienen laboratorios virtuales que podemos encontrar en muchos sitios web los cuales pretenden ofrecer una solución a esto. Pero la mayoría de estos sitios presentan problemas, ya que algunas pruebas requieren una gran capacidad de cómputo y una gran cantidad de recursos, de tal manera que un solo servidor se vuelve ineficaz para atender múltiples solicitudes de usuarios que necesitan una gran disponibilidad de recursos para las simulaciones o pruebas de sus circuitos.

Como ejemplo de ello podemos tener un microprocesador, el cual se compone de millones de compuertas, transistores, diodos, entre otros. Los cuales en conjunto realizan millones de operaciones. Así que realizar pruebas a un circuito de esta magnitud es una tarea bastante ardua y desgastante, además requiere una gran capacidad de cómputo y recursos disponibles.

Por tal motivo nos hemos dado a la tarea de desarrollar un sistema que nos permita ofrecer laboratorios donde usuarios podrán realizar pruebas o simulaciones de circuitos electrónicos de una manera eficiente ya que pretendemos crear una Grid Desktop Computing para atender todas aquellas peticiones de los usuarios, esto sin que se sufran de un agotamiento de recursos, caídas del sistema o simplemente la molestia de tener que esperar tiempos demasiado largos para obtener los resultados de sus pruebas. Aunadamente a ello se pretende realizar una buena planificación para la distribución de cargas de

trabajo utilizando el modelo de programación dataflow , logrando de esta manera una aplicación que trabaje en un ambiente totalmente distribuido.

2. Programación del modelo dataflow

La programación del modelo dataflow abstrae los procesos de computación como un grafo dataflow que se compone de vértices y bordes dirigidos.

El vértice tiene dos entidades:

• Los datos creados durante el computo o la entrada de datos inicial • El modulo de ejecución para generar el correspondiende vértice de datos

Los bordes dirigidos conectan los vértices los cuales indican las relaciones de dependencia entre los vértices. Un vértice toma los vértices dependientes como entradas. Un vértice es un vértice inicial si no hay bordes apuntándolo, pero este tiene bordes apuntado hacia otros vértices; correspondientemente, un vértice es llamado vértice resultado si este no tiene bordes apuntando hacia otros vértices y hay bordes apuntándolo. Un vértice inicial no tiene un modulo de ejecución asociado.

2.1. Espacio de nombres para los vértices. Cada vértice tiene un único nombre en el grafo dataflow, el nombre consiste de tres partes: categoría, versión y espacio.Asi el nombre es denotado como <C, T, S>. La categoría denota las diferentes clases de vértices, la versión denota el índice para el vértice a lo largo del tiempo que dure el proceso de cómputo, el espacio denota el índice del vértice a lo largo del espacio durante la ejecución.

2.2. Especificación del modulo de ejecución Las instrucciones/código específicamente son las que se debe ejecutar, cuando es llamado el modulo de ejecución y usado para generar la salida de cada vértice, los usuarios necesitan heredar el modulo de la clase en la librería para escribir el código de ejecución del vértice, en particular los usuarios necesitan implementar 3 funciones virtuales:

• Nombre del modulo SetName() : especifica un nombre para el modulo de ejecución, el cual es usado como un identificador durante la edición del grafo de dependencia de datos.

• Void Compute( Vertex[] inputs): implementado por los usuarios para generar la salida tomando la entrada de datos del vértice. La entrada de datos es denotada por el el array imputs. Cada elemento de imputs consiste de un nombre y un buffer de datos.

• Byte[] SetResult() : llamado por el sistema para obtener la salida de datos después de que Compute() ha terminado.

2.3. Creación del grafo dataflow

El API dataflow provee dos funciones para la composición del grafo estatico de dependencia de datos:

• CreateVertex (vertex, ModuleName): es usado para especificar el nombre y correspondencia del modulo de ejecución para cada vértice.

• Dependency( vertex, InputVertex): es usado para agregar una Y como X dependencia del vértice

Dos funciones son implementadas para el conjunto inicial y los vértices resultado como las siguientes:

• SetInicialVertex (vertex, file) • SetResultVertex( vertex,file)

Ejemplo:

Dada la… Vt=M*Vt-1 nosotros particionamos la matriz y el vector por filas en m

piezas respectivamente

El grafo correspondiente es ilustrado por la figura 1.- Para nombrar los vértices, Categoria = M denota la matriz de vértices y Categoria = V denota el vector de vértices. Para cada i-th del vector de vértices, las relaciones de datos deberían ser especificadas como<V, t, i> ← {<M, 0, i>, <V, t-1, j>} (j=1,…m)

3. Arquitectura y diseño

Nuestro sistema consiste de un simple maestro y multiples trabajadores como se observa en la figura 1. El maestro es responsable por aceptar trabajos de usuarios organizando a varios trabajadores para trabajar conjuntamente, envía peticiones de ejecución a los trabajadores. Cada trabajador contribuye con CPU y recursos de disco duro y espera peticiones de ejecución del maestro.

3.1. La estructura del maestro

El maestro es el encargado de monitorear el estado de cada trabajador despachándoles tareas listas para los trabajadores adecuados y seguir el proceso de cada trabajo de acuerdo al grafo de dependencia de datos. El maestro tiene 4 principales componentes:

• El componente de asociación: mantiene una lista de nodos de trabajadores disponibles cuando algunos nodos se asocian o salen del sistema la lista es actualizada correspondientemente la asociación es mantenida atreves del envió de señales entre maestro y trabajadores la señal también lleva información del estado acerca del trabajador como CPU, memoria y uso de disco

• El componente de registro: Mantiene la posición de la información para cada vértice disponible. En particular este mantiene una lista de índices para cada vértice de datos disponible. Cada vértice tiene un index, los cuales listan a los trabajadores que datos tomar.

• El componente grafo dataflow: mantiene el grafo de dependencia de datos para cada trabajo, sigue la pista de la disponibilidad de vértices y explora tareas listas. Cuando encuentra tareas listas este debe notificar al componente planificador.

• El componente planificador: despacha tareas listas a los trabajadores adecuados para que las ejecuten. Por cada tarea, el maestro notifica a los trabajadores de entradas e inicializa el modulo de ejecución asociado para generar la salida de datos.

3.2. La estructura de un trabajador

Los trabajadores trabajan en modo peer to peer . Para cooperar con el maestro, cada trabajador tiene dos funciones: ejecución de las peticiones del maestro y almacenamiento del vértice de datos. Correspondientemente hay 2 componentes importantes en cada trabajador.

• El componente ejecutor: Recibe y ejecuta peticiones del maestro, trae las entradas del componente de almacenamiento y genera la salida para el componente de almacenamiento y notifica al maestro acerca del vértice disponible de datos de salida.

• Componente de almacenamiento: es responsable de manejar y almacenar el vértice de datos de los ejecutores y atiende las peticiones. Actualmente los componentes de almacenamiento en los trabajadores se ejecutan como un servicio de almacenamiento distribuido. Para el manejo de fallos, las peticiones del maestro, los componentes de almacenamiento, pueden hacer los datos persistentes localmente o replicar algunos vértices en sitios remotos para mejorar la fiabilidad y disponibilidad.

3.3. Sistema de interacción

Al recibir misiones de los usuarios, incluyendo el grafo dataflow y la ejecución de modulos, el nodo maestro debe crear una instancia como un hilo para cada modulo, basado en la plataforma .NET el maestro serializa el modulo de ejecución como un objeto, y luego envía este a los trabajadores y luego se los envía a los trabajadores cuando despacha los vértices de ejecución.

Para comenzar la ejecución, el nodo maestro primero envía el vértice inicial a los trabajadores. Cuando un trabajador recibe el vértice este debería mantenerlo en el modulo de almacenamiento y luego notificar al componente de registro atreves de un índice publicando un mensaje.

Todo el tiempo el componente de registro recibe un índice que publica un mensaje para el vértice x, este actualiza el índice de x, y luego notifica al componente del grafo dataflow para que compruebe si hay un vértice en ejecución esperando a x, si es así, el vértice listo debería planear como ejecutar la tarea. El componente de planificación envía la petición de ejecución a los trabajadores candidatos. La petición de ejecución lleva el objeto serializado al modulo de ejecución correspondiente y localiza la información del vértice de datos de entrada. Después de recibir este, el trabajador primero trae los datos de entrada y luego descerializa el objeto de ejecución y lo ejecuta.

Para mejorar la escalabilidad del sistema, los trabajadores transfieren el vértice de datos en una manera P2P. Siempre que el componente ejecutor reciba una petición de ejecución del nodo maestro este envía la petición al componente de almacenamiento local, si no hay una copia local para los datos solicitados el componente de almacenamiento debería traer los datos de un trabajador remoto de acuerdo a la ubicación especificada en la petición de ejecución. Después todas las entradas de datos estarán disponibles en el nodo trabajador, el componente ejecutor crea una instancia – hilo por cada modulo de ejecución basado en el objeto serializado del maestro, lo alimenta con los vértices de entrada y comienza el hilo. Después de que finaliza el cómputo, el componente ejecutor guarda el vértice resultado dentro del componente de almacenamiento local y notifica al componente de registro.

El componente de almacenamiento mantiene los datos del vértice que se están ocupando en memoria mientras sostiene los datos que en ese momento no se están ocupando en disco duro. El vértice de datos deberá ser vertido al disco duro asíncronamente cuando sea necesario reducir el espacio de memoria. El trabajador programa el tráfico de red y la ejecución de múltiples tareas como un pipeline para optimizar el performance.

3.4. Planificación

En el presente diseño la planificación es realizada por el maestro que da prioridad a los datos locales y a la historia de funcionamiento de los trabajadores, para una planeación eficiente, el tamaño de cada vértice de datos de entrada y el poder de computo, como ejemplo: la frecuencia del CPU, deben ser tomadas para el balanceo de cargas. El planificador recoge la información de funcionamiento

relacionada para cada modulo de ejecución, como el tamaño de los datos de entrada y el tiempo consumido basados en este historial de información, nosotros podremos predecir el tiempo de ejecución para cada modulo de ejecución

4. Pruebas y resultados 4.1. Prueba realizada sobre el sistema

Consiste en tener un archivo ejecutable el cual se pretende asignar al sistema para que sea él, el encargado de realizar el cómputo, probando así que se realiza una distribución de trabajo adecuada.

Por tanto es necesario observar el panorama general de la prueba en el cual describo cada parte de la prueba y los resultados que se esperaban alcanzar.

En primer instancia se tiene un cliente del tipo usuario el cual tiene como función cargar el archivo ejecutable junto con sus parámetros de entrada almacenarlo en un contenedor de vértices junto con información adicional, la cual nos indica el PID del proceso original, para que posteriormente envié este contenedor al maestro y este se encargue de realizar el computo del mismo. Después que el maestro ha recibido el contenedor tiene como funciones; encontrar al mejor trabajador para que realice el trabajo, al termino de esto procede a enviarle el archivo a ejecutar junto con los parámetros de entrada, en caso de que esos parámetros los tenga algún otro trabajador el maestro le indica específicamente cual es el trabajador que le entregará esos parámetros que necesita para proceder con la ejecución. Por ultimo se encarga de obtener el resultado final para regresárselo al usuario que le asigno la tarea.

Por otra parte el trabajador recibe el archivo ejecutable que le han asignado, lo coloca en un directorio de trabajo y procede a verificar si necesita algunos parámetros de entrada que se encuentren en otro trabajador, de ser así se comunica con aquel otro trabajador de forma peer to peer y obtiene lo que necesita, posteriormente procede a ejecutar el archivo y publica su resultado por si algún otro trabajador lo requiere, de tal manera que al final el maestro recolecta el resultado final y lo manda al usuario que le solicito la tarea. Véase figura 2

Figura 2.- Descripción de la forma de trabajo del sistema Desktop Grid Computing.

Al final de todo este proceso se espera observar que el archivo ejecutable lo computo un trabajador, además se tiene que mostrar la pantalla de ejecución en el trabajador y el usuario obtiene el estatus en que se desarrollo el proceso. Véase Figura 3.

Figura 3.- Prueba exitosa llevada a cabo entre todos los elementos del Desktop Grid Computing

En la imagen anterior se observa la prueba realizada, donde cada ovalo rojo indica el resultado y como se fue transmitiendo desde el archivo que se ejecuto en el trabajador, posteriormente al maestro y este a su vez lo regresa al usuario que le asigno la tarea. Es importante denotar que la operación finalizo de manera correcta y satisfactoria.

4.2. Resultados obtenidos

Como resultados se logro la creación de un cliente el cual contiene todas las funciones anteriormente mencionadas, para lograr enviar un conjunto de archivos almacenados en un contenedor de vértices el cual tiene que enviar al maestro.

Posteriormente se obtuvo como otro resultado la generación de un maestro con la capacidad de ser cliente y/o servidor dependiendo de la función que esté realizando, el cual levanta la comunicación a través de un puerto TCP 777.

También dentro del maestro se logro crear una clase dedicada exclusivamente a obtener los recursos de cada trabajador, por ejemplo, tamaño de la memoria, memoria libre y ocupada, espacio libre en disco duro, velocidad de procesador, entre otros.

Por último se logro la creación de los trabajadores donde cada uno actúa como un servidor en caso de realizar comunicación con el maestro y como un cliente si se pretende realizar comunicación con algún otro trabajador, de esta manera cada trabajador levanta su servicio a través de un puerto TCP diferente.

5. Conclusiones

Nuestro sistema Desktop Gris Computing resuelve diversos problemas que se generan en muchos sitios de internet dado que evita una saturación y agotamiento de recursos del servidor encargado de ofrecer el servicio de laboratorios virtuales, obteniendo con ello una distribución de trabajo en una malla de computadoras de diversas características logrando así la ejecución un proceso de manera satisfactoria. Por otra aprovecha recursos de otras maquinas para que sean ellas las que generen el trabajo evitando con ello que el servidor sufra algún tipo de falla, generando además un mejor servicio para los usuarios que necesiten realizar pruebas a sus circuitos digitales virtuales.

Aún queda mucho trabajo por realizar como una estructura más robusta para evitar que ciertos fallos dejen en espera a ciertos procesos a la hora de la ejecución de los vértices. Por tanto en un futuro se pretende realizar los trabajos a futuro.

6. Trabajos futuros • Como primer punto es importante generar un mejor tratamiento a fallos • Evolucionar para llevar al sistema a formar parte de los sistemas de tercera

generación, donde estos están enfocados a dar servicios dependiendo del contexto de cada prueba que se esté realizando en ese momento. Se esta manera se pretende utilizar algoritmos de distribución diferentes para cada prueba que se requiera realizar.