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.