![BOINC Logo custom.png](http://wikiimg.tojsiabtv.com/wikipedia/commons/thumb/1/15/BOINC_Logo_custom.png/300px-BOINC_Logo_custom.png)
La tecnología cliente-servidor de BOINC se refiere al modelo bajo el cual funciona BOINC . El marco BOINC consta de dos capas que operan bajo la arquitectura cliente-servidor . Una vez que el software BOINC está instalado 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 .
Diseño y estructura de BOINC
- BOINC está diseñado para ser una estructura gratuita para cualquiera que desee iniciar un proyecto de computación distribuida.
- BOINC consta de un sistema de servidor y un software de cliente que se comunican entre sí para distribuir, procesar y devolver unidades de trabajo.
Estructura del servidor
Una parte importante del sistema BOINC es el servidor backend. El servidor puede ejecutarse en una o varias máquinas para permitir que BOINC escale fácilmente a proyectos de cualquier tamaño. Los servidores BOINC se ejecutan en computadoras basadas en Linux y utilizan Apache , PHP y MySQL para sus sistemas web y de bases de datos .
Los cálculos científicos se ejecutan en las computadoras de los participantes. Después de cargar desde el cliente del usuario a la base de datos de un investigador científico, el servidor backend valida y analiza los resultados. El proceso de validación implica ejecutar todas las tareas en múltiples PC colaboradores y comparar los resultados.
Los servidores BOINC también proporcionan estas características:
- Redundancia homogénea (envío de unidades de trabajo solo a equipos de la misma plataforma , por ejemplo: solo Win XP SP2 )
- goteo de la unidad de trabajo (enviar información al servidor antes de que se complete la unidad de trabajo)
- programación de la localidad (envío de unidades de trabajo a computadoras que ya tienen los archivos necesarios y creación de trabajo a pedido)
- distribución del trabajo basada en los parámetros del host (las unidades de trabajo que requieren 512 MB de RAM, por ejemplo, solo se enviarán a hosts que tengan al menos esa cantidad de RAM [1] )
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 unidades de trabajo.
El programa CGI del planificador maneja las solicitudes de los clientes, recibe los resultados completos y envía nuevos trabajos para computar. El programador no obtiene resultados disponibles directamente desde la base de datos. En cambio, un demonio alimentador carga tareas desde la base de datos y las mantiene en un bloque de memoria compartida , que lee el programador. El alimentador llena periódicamente "ranuras" vacías en el bloque de memoria compartida después de que el programador ha 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 popular sería comparar los resultados entre sí. El validador puede tener un código de proyecto personalizado para realizar una comparación aproximada entre los resultados, o puede realizar 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 válidos, los usuarios que arrojaron resultados legítimos reciben crédito por ello y se elige un "resultado canónico" [¿ por quién? ] . Si el validador no puede determinar qué resultados son válidos o declara que todos los resultados no son válidos, se pueden generar nuevos resultados y repetir el ciclo hasta que el validador pueda determinar qué resultados son válidos.
A continuación, el demonio asimilador procesa el resultado canónico utilizando código específico del proyecto. Por ejemplo, algunos proyectos pueden analizar el archivo y almacenar información en una base de datos, otros pueden simplemente copiar el archivo en otro lugar. Un asimilador también puede generar más unidades de trabajo en función 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 maneja las transiciones de estado de las unidades de trabajo y los resultados. También genera resultados a partir de unidades de trabajo cuando se crean por primera vez y cuando se necesitan más (por ejemplo, si un resultado resulta no válido).
Debilidades del diseño del servidor
- Los servidores BOINC no son tan fáciles de implementar como el cliente BOINC ya que [ cita requerida ] requieren una gran cantidad de scripts.
- El sitio web del proyecto BOINC Server hace un mal trabajo al almacenar una base de datos compilada de scripts del lado del servidor para aquellos que deseen crear un proyecto BOINC. [ cita requerida ]
- El servidor BOINC se puede implementar en sistemas Windows Vista (o superior) [ cita requerida ] (ya que son compatibles con POSIX y pueden ejecutar aplicaciones UNIX) pero la estructura de diseño de Windows hace que esto sea más difícil y más caro que simplemente usar "off -el-estante "Linux.
Estructura del cliente
![](http://wikiimg.tojsiabtv.com/wikipedia/commons/thumb/f/f1/BOINC_screenshot.png/220px-BOINC_screenshot.png)
BOINC en el cliente está estructurado en varias aplicaciones independientes. Estos se comunican entre sí mediante el mecanismo de llamada a procedimiento remoto (RPC) 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 archivos binarios de las aplicaciones científicas estén actualizados y programa los recursos de la CPU entre las aplicaciones científicas (si hay varias instaladas).
- Aunque el cliente principal es capaz de descargar nuevas aplicaciones científicas, no se actualiza a sí mismo. Los autores de BOINC sintieron que hacerlo representaba un riesgo de seguridad inaceptable [ cita requerida ] , así como todos los riesgos que los procedimientos de actualización automática tienen en la informática.
- En Unix , el cliente central generalmente se ejecuta como un demonio (u ocasionalmente como un trabajo 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 superiores añaden, durante la instalación, la opción de "Instalación del servicio".
- Dependiendo de cómo se instaló el software de cliente BOINC, puede ejecutarse en segundo plano como un demonio o iniciarse cuando un usuario individual inicia sesión (y se detiene cuando el usuario cierra la sesión). La gestión de la versión de software y la gestión de la unidad de trabajo proporcionada por el cliente central simplifica enormemente la codificación de las aplicaciones científicas.
- Una o varias aplicaciones científicas. Las aplicaciones científicas realizan el cálculo científico básico. 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 y para intercambiar estadísticas con el servidor.
- boincmgr (o boincmgr.exe ), una GUI que se comunica con la aplicación principal mediante llamadas a procedimientos remotos . De forma predeterminada, un cliente central solo permite conexiones desde la misma computadora, pero se puede configurar para permitir conexiones desde otras computadoras (opcionalmente usando autenticación de contraseña); este mecanismo permite que una persona administre una granja de instalaciones BOINC desde una sola estación de trabajo. Un inconveniente del uso de mecanismos RPC es que a menudo se considera que son riesgos de seguridad porque pueden ser la ruta por la que los piratas informáticos pueden inmiscuirse en los equipos de destino (incluso si están configurados para conexiones desde el mismo equipo).
- La GUI está escrita utilizando el kit de herramientas multiplataforma WxWidgets , que brinda la misma experiencia de usuario en diferentes plataformas. Los usuarios pueden conectarse a los clientes centrales de BOINC, pueden instruir a esos clientes para que instalen nuevas aplicaciones científicas, pueden monitorear el progreso de los cálculos en curso y pueden ver los registros de mensajes del sistema BOINC.
- El salvapantallas BOINC . Esto proporciona un marco en el que las aplicaciones científicas pueden mostrar gráficos en la ventana del protector de pantalla del usuario. Los protectores de pantalla BOINC se codifican mediante la API de gráficos BOINC, OpenGL y el kit de herramientas GLUT . Normalmente, los protectores de pantalla BOINC muestran gráficos animados que detallan el trabajo en curso, tal vez mostrando gráficos o tablas u otros gráficos de visualización de datos.
- Algunas aplicaciones científicas no ofrecen la función de protector de pantalla (o dejan de proporcionar imágenes de protector de pantalla cuando están inactivas). En esta circunstancia, el protector de pantalla muestra un pequeño logotipo BOINC que rebota por la pantalla.
Dado que BOINC tiene características que pueden volverlo invisible para el usuario típico, existe el riesgo de que se produzcan instalaciones no autorizadas y difíciles de detectar. Esto ayudaría a la acumulación de puntos de crédito BOINC por parte de los aficionados que compiten con otros por el estatus dentro de la subcultura de crédito BOINC.
Plataformas de clientes
Sistema operativo | Hardware | Ejemplos de | Estado |
---|---|---|---|
Linux | IA-32 y AMD64 | PC y servidores | La mayoría de los proyectos de Linux requieren Linux de 64 bits. Los proyectos de Linux de 32 bits podrían requerir la instalación de bibliotecas de 32 bits si se ejecutan en Linux de 64 bits. |
Mac OS | X86-64 , ARMv8 | Los diferentes clientes BOINC utilizados estarán disponibles para PowerPC, IA-32 y AMD64. El cliente AMD64 era capaz de ejecutar aplicaciones IA-32 si el servidor BOINC lo admite. BOINC Manager 7.16.13 es para X-86-64 y ARMv8. | |
Ventanas | IA-32 y AMD64 | Hay diferentes clientes BOINC disponibles para IA-32 y AMD64. El cliente de 64 bits ejecutará aplicaciones de 32 bits si el servidor BOINC lo admite. | |
Raspbian ( Linux ) | BRAZO | Frambuesa pi | Muy pocas aplicaciones cliente disponibles |
Android ( Linux ) | ARM , MIPS o IA-32 | Smartphones y tablets | Pocas aplicaciones de cliente disponibles. Algunos proyectos pueden requerir clientes no oficiales (NativeBOINC) |
Ver también
- BOINC
- Computación distribuída
Referencias
- ^ Transición de SETI @ home a BOINC