Desarrolladores:
Tomás Girardi - Pablo Benaprés.
Tomás Girardi - Pablo Benaprés.
BioGym es una aplicación multiplataforma escrita en java, que fue pensada, en un principio,
como una herramienta para repartir la carga de entrenamientos de redes neuronales y GMMs
utilizados por otro software desarrollado por nosotros, al que llamamos bioid (software de
reconocimiento de identidad basado en parametros biométricos).
De esta forma, el principal objetivo era, inicialmente, permitir capturar los parametros
biométricos de una persona desde un terminal liviano, pero relegando el procesamiento
de estos datos a computadores de mayor rendimiento. A esta idea se agregaba el objetivo
de que cada terminal pudiese pedir a otro que se encargue de un entrenamiento que el primero
no pueda realizar o que haga de manera más lenta. Intentando lograr así, una comunidad
de computadores trabajando en coordinación para cumplir una tarea que suele requerir de
muchos recursos: entrenar.
Durante el desarrollo de BioGym se extendió
el uso de éste para cualquier tipo de entrenamiento o servicio remoto en el que
se requiera procesamiento de datos, mientras estos procesos puedan cumplir con ciertas
condiciones.
Los entrenamientos de sistemas basados en softcomputing demandan generalmente grandes
capacidades de procesamiento y suelen requerir de largos intervalos de tiempo para su realización.
De ahí la importancia de contar con una herramienta que permita balancear las cargas cuando se intenta
realizar una serie de entrenamientos o un mismo entrenamiento sobre una extensa base de datos (por ejemplo: intentando
entrenar redes neuronales para reconocer las caras de todo el personal de una gran empresa).
Además, no contar con una herramienta similar, puede significar que los datos deban ser capturados y analizados
por el mismo computador, lo cual deja fuera la posibilidad de ahorrar dinero realizando la captura con terminales
livianos de menor costo.
Delegar un proceso de entrenamiento a un terminal a elección (que esté
corriendo biogym).
Los terminales deben ser capaces de comunicarse información relevante entre ellos.
El sistema debe ser capaz de limitar la cantidad de entrenamientos corriendo en cada terminal
al mismo tiempo.
El software debe facilitar al usuario la integración de un terminal a la comunidad de
terminales.
El software debe facilitar al usuario la adición de nuevos terminales a su lista de
terminales "conocidos" (aquellos que el usuario sabe que corren biogym).
El software debe facilitar al usuario la tarea de agregar nuevos servicios de entrenamiento
a un terminal.
La comunicación NO debe ser de tipo cliente/servidor; todos los terminales deben ser
capaces de ejercer como clientes y como servidores, dependiendo de lo que esté haciendo
el software.
A la idea original del sistema se pueden anexar una serie de mejoras. Las posibilidades son infinitas, pero aquí hay un listado de algunas que han ido surgiendo durante el proceso de desarrollo:
Que el software sea capaz de decidir que terminal es el más apto para realizar
un entrenamiento dado y que sea a éste al primero que contacte.
Que los usuarios puedan opinar sobre el rendimiento de un terminal, para ayudar a otros
usuarios.
Que el software sea capaz de llevar registros y desplegar estadísticas.
Generar una arquitectura de software que permita agregar mejoras (plugins) de forma
sencilla.
Implementar un sistema de "logs" que sea útil.
(Objetivo de programación: utilizar todas las herramientas de java para la facilidad
de mantención, debugeo y mejoras del software).
Biogym soluciona el problema recurrente de poca disponibilidad de recursos para realizar un proceso
sumamente pesado: entrenar; sea éste un entrenamiento de redes neuronales, algoritmos genéticos,
GMMs, etc. Esto lo hace repartiendo la carga de entrenamiento entre terminales habilitados para realizar la
tarea. Esto permite, a su vez, que la captura de datos pueda realizarse con terminales livianos (de bajo costo),
mientras los datos son analizados en terminales más potentes.
Para cumplir con esta misión, biogym consta de dos formas de comunicación:
Una se realiza continuamente mediante sockets UDP y permite que los terminales intercambien entre ellos
información relevante como, por ejemplo: el número de núleos del procesador, la velocidad
del procesador, los servicios de entrenamiento capaz de atender, la disponibilidad para realizar una tarea de
entrenamiento, etc.
El segundo tipo de comunicación consiste en sockets TCP que permiten la conexion entre dos terminales que ya han acordado
el traspaso de una tarea de entrenamiento (basandose en la información compartida mediante el primer proceso de comunicación).
Además, el sistema es capaz de limitar la carga de cada terminal, ya que cada uno puede definir cuantos entrenamientos
simultáneos está dispuesto a atender que provengan desde un terminal remoto y cuantos que provengan desde él mismo.
El proceso de configurar y manejar el sistema se ve facilitado, para el usuario, gracias a una GUI con todas las herramientas
necesarias para operarlo y gracias a programación multihebra, que permite que el sistema realize todos los procesos
de comunicación sin molestar al operador, mientras este maneja el software mediante la GUI.