Tecnología cliente-servidor BOINC

La tecnología cliente-servidor de BOINC ^{[ 1 ]} se refiere al modelo bajo el cual funciona BOINC . El marco de trabajo de BOINC consta de dos capas que operan bajo la arquitectura cliente-servidor . Una vez instalado el software BOINC en una máquina, el servidor comienza a enviar tareas al cliente . Las operaciones se realizan en el lado del cliente y los resultados se cargan en el lado del servidor .

• BOINC está diseñado para ser una estructura gratuita para cualquier persona que desee iniciar un proyecto de computación distribuida.
• BOINC consta de un sistema de servidor y un software cliente que se comunican entre sí para distribuir, procesar y devolver unidades de trabajo.

Una parte fundamental del sistema BOINC es el servidor backend. Este servidor puede ejecutarse en una o varias máquinas, lo que permite que BOINC se adapte fácilmente a proyectos de cualquier tamaño. Los servidores BOINC se ejecutan en ordenadores con sistema operativo Linux y utilizan Apache , PHP y MySQL para sus sistemas web y de bases de datos .

Los cálculos científicos se ejecutan en los ordenadores de los participantes. Tras subir los datos desde el cliente del usuario a la base de datos del investigador, el servidor backend valida y analiza los resultados. El proceso de validación consiste en ejecutar todas las tareas en varios ordenadores de los participantes y comparar los resultados.

Los servidores BOINC también ofrecen estas características:

• Redundancia homogénea (envío de unidades de trabajo únicamente a ordenadores de la misma plataforma ; por ejemplo: solo Windows XP SP2 ).
• Flujo de información de la unidad de trabajo (envío de información al servidor antes de que la unidad de trabajo finalice).
• Planificación local (envío de unidades de trabajo a ordenadores que ya disponen de los archivos necesarios y creación de trabajo bajo demanda).
• distribución del trabajo en función de los parámetros del host (por ejemplo, las unidades de trabajo que requieren 512 MB de RAM solo se enviarán a hosts que tengan al menos esa cantidad de RAM ^{[ 2 ]} ).

El servidor consta de dos programas CGI y (normalmente) cinco demonios , escritos en C++ . Los cálculos que deben realizar los clientes se denominan unidades de trabajo . Un resultado describe una instancia de una unidad de trabajo, incluso si no se ha completado. Un proyecto no crea resultados explícitamente; el servidor los crea automáticamente a partir de las unidades de trabajo.

El programa CGI del planificador gestiona las solicitudes de los clientes, recibe los resultados completados y envía nuevas tareas para su procesamiento. El planificador no obtiene los resultados disponibles directamente de la base de datos. En su lugar, un demonio de alimentación carga las tareas desde la base de datos y las almacena en un bloque de memoria compartida , que el planificador lee. El alimentador rellena periódicamente los espacios vacíos en el bloque de memoria compartida después de que el planificador haya enviado esos resultados a un cliente.

Cuando se completan y devuelven todos los resultados de una unidad de trabajo, el validador los comprueba. Un método común consiste en comparar los resultados entre sí. El validador puede utilizar código de proyecto personalizado para realizar una comparación aproximada entre los resultados, o bien una comparación bit a bit. Si el validador determina que al menos algunos de los resultados son válidos, marca la unidad de trabajo y los resultados válidos como tales, se otorga crédito a los usuarios que devolvieron resultados legítimos y se elige un "resultado canónico". Si los resultados no coinciden, o si alguno de ellos no se informa antes de su fecha límite, el servidor genera una instancia adicional del trabajo y la envía a un tercer host. Este proceso se repite hasta que se encuentra un quórum de resultados coincidentes o se alcanza un límite en el número de instancias. ^{[ 3 ]}

A continuación, el demonio asimilador procesa el resultado canónico mediante código específico del proyecto. Por ejemplo, algunos proyectos analizan el archivo y almacenan la información en una base de datos, mientras que otros simplemente lo copian a otra ubicación. Un asimilador también puede generar más unidades de trabajo a partir de los datos devueltos.

El demonio file_deleter elimina los archivos de salida después de que el asimilador los haya procesado, y elimina los archivos de entrada que ya no son necesarios.

El demonio de transición gestiona las transiciones de estado de las unidades de trabajo y los resultados. También genera resultados a partir de las unidades de trabajo cuando se crean por primera vez y cuando se necesitan más (por ejemplo, si un resultado resulta inválido).

BOINC en el cliente está estructurado en varias aplicaciones independientes. Estas se comunican entre sí mediante el mecanismo de llamada a procedimiento remoto (RPC) de BOINC.

Estas aplicaciones de componentes son:

• El programa boinc (o boinc.exe ) es el cliente principal.
• El cliente principal es un proceso que:
  • Se encarga de las comunicaciones entre el cliente y el servidor.
  • El cliente principal también descarga aplicaciones científicas, proporciona un mecanismo de registro unificado, se asegura de que los binarios de las aplicaciones científicas estén actualizados y distribuye los recursos de la CPU entre las aplicaciones científicas (si hay varias instaladas).
  • Si bien el cliente principal es capaz de descargar nuevas aplicaciones científicas, no se actualiza automáticamente.
  • En Unix , el cliente principal generalmente se ejecuta como un demonio (o, en ocasiones, como una tarea programada con cron ).
  • En Windows, BOINC inicialmente no era un servicio de Windows, sino una aplicación normal. BOINC Client para Windows, versiones 5.2.13 y posteriores, añaden, durante la instalación, la opción de "Instalación como servicio".
  • Dependiendo de cómo se haya instalado el software cliente de BOINC, este puede ejecutarse en segundo plano como un demonio o iniciarse cuando un usuario individual inicia sesión (y detenerse cuando el usuario cierra sesión). La gestión de versiones del software y el manejo de unidades de trabajo que ofrece el cliente principal simplifican enormemente la programación de aplicaciones científicas.
• Una o varias aplicaciones científicas. Estas aplicaciones realizan los cálculos científicos fundamentales. Existe una aplicación científica específica para cada uno de los proyectos de computación distribuida que utilizan el marco BOINC. Las aplicaciones científicas utilizan el demonio BOINC para cargar y descargar unidades de trabajo e intercambiar estadísticas con el servidor.
• boincmgr (o boincmgr.exe ) es una interfaz gráfica de usuario que se comunica con la aplicación principal mediante llamadas a procedimientos remotos (RPC ). Por defecto, el cliente principal solo permite conexiones desde el mismo equipo, pero puede configurarse para permitir conexiones desde otros equipos (opcionalmente mediante autenticación por contraseña). Este mecanismo permite que una persona administre un conjunto de instalaciones de BOINC desde una única estación de trabajo. Una desventaja del uso de mecanismos RPC es que a menudo se consideran riesgos de seguridad, ya que pueden ser la vía por la que los hackers pueden infiltrarse en los equipos objetivo (incluso si están configurados para conexiones desde el mismo equipo).
• La interfaz gráfica de usuario (GUI) está desarrollada con el kit de herramientas multiplataforma WxWidgets , lo que proporciona la misma experiencia de usuario en diferentes plataformas. Los usuarios pueden conectarse a los clientes principales de BOINC, indicarles que instalen nuevas aplicaciones científicas, supervisar el progreso de los cálculos en curso y consultar los registros de mensajes del sistema BOINC.
• El salvapantallas BOINC proporciona un marco que permite a las aplicaciones científicas mostrar gráficos en la ventana del salvapantallas del usuario. Los salvapantallas BOINC se programan utilizando la API gráfica BOINC, OpenGL y el kit de herramientas GLUT . Normalmente, los salvapantallas BOINC muestran gráficos animados que detallan el trabajo en curso, como gráficos, diagramas u otras visualizaciones de datos.
• Algunas aplicaciones científicas no ofrecen la función de protector de pantalla (o dejan de mostrar imágenes de protector de pantalla cuando están inactivas). En este caso, el protector de pantalla muestra un pequeño logotipo de BOINC que rebota por la pantalla.

Dado que BOINC cuenta con funciones que pueden hacerlo invisible para el usuario común, existe el riesgo de que se produzcan instalaciones no autorizadas y difíciles de detectar. Esto facilitaría la acumulación de puntos de crédito BOINC por parte de aficionados que compiten entre sí por obtener estatus dentro de la subcultura de los créditos BOINC.

• Infraestructura Abierta de Berkeley para Computación en Red (BOINC)
• Informática para voluntarios