Estructura cliente-servidor de informática voluntaria BOINC
Diagrama visual de la estructura cliente-servidor BOINC.
La tecnología cliente-servidor BOINC [1] se refiere al modelo bajo el cual trabaja 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 informática 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 varias PC de los contribuyentes y comparar los resultados.
Los servidores BOINC también ofrecen estas características:
redundancia homogénea (envío de unidades de trabajo solo a computadoras de la misma plataforma , por ejemplo: solo Win XP SP2 )
goteo de la unidad de trabajo (envío de información al servidor antes de que se complete la unidad de trabajo)
programación de localidad (enviar unidades de trabajo a computadoras que ya tienen los archivos necesarios y crear trabajo bajo demanda)
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 [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 unidades de trabajo.
El programa planificador CGI maneja las solicitudes de los clientes, recibe los resultados completos y envía nuevos trabajos para calcular. El programador no obtiene resultados disponibles directamente de 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 el programador lee. El alimentador llena periódicamente "espacios" vacíos 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 verifica. 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 difusa 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". Si los resultados no coinciden, o si uno de los resultados no se informa antes de la fecha límite, el servidor genera una instancia adicional del trabajo y la envía a un tercer host. Esto se repite hasta que se encuentre un quórum de resultados coincidentes o se alcance un límite en el número de instancias. [3]
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 no es válido).
BOINC en el cliente está estructurado en varias aplicaciones independientes. Estos se intercomunican mediante el mecanismo de llamada a procedimiento remoto (RPC) BOINC.
Estas aplicaciones componentes son:
El programa boinc (o boinc.exe ) es el cliente principal.
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 programa recursos de CPU entre aplicaciones científicas (si hay varias instaladas).
Aunque el cliente principal es capaz de descargar nuevas aplicaciones científicas, no se actualiza por sí solo. Los autores de BOINC sintieron que hacerlo representaba un riesgo de seguridad inaceptable [ cita necesaria ] , así como todos los riesgos que tienen los procedimientos de actualización automática en la informática.
En Unix , el cliente principal generalmente se ejecuta como un demonio (u ocasionalmente como una tarea cron ).
En Windows, BOINC inicialmente no era un servicio de Windows, sino una aplicación normal. Cliente BOINC para Windows, Versiones 5.2.13 y superiores agregan, durante la instalación, la opción de "Instalación de Servicio".
Dependiendo de cómo se instaló el software del 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 versiones de software y el manejo de unidades de trabajo proporcionadas por el cliente principal simplifican enormemente la codificación de aplicaciones científicas.
Una o varias aplicaciones científicas. Las aplicaciones científicas realizan el cálculo científico central. 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 ), 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 gestione un conjunto de instalaciones BOINC desde una única estación de trabajo. Una desventaja del uso de mecanismos RPC es que a menudo se consideran riesgos de seguridad porque pueden ser la ruta por la cual los piratas informáticos pueden invadir computadoras específicas (incluso si están configuradas para conexiones desde la misma computadora).
La GUI está escrita utilizando el kit de herramientas WxWidgets multiplataforma , proporcionando la misma experiencia de usuario en diferentes plataformas. Los usuarios pueden conectarse a los clientes principales de BOINC, pueden indicarles a esos clientes 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 mediante el cual las aplicaciones científicas pueden mostrar gráficos en la ventana del protector de pantalla del usuario. Los salvapantallas BOINC están codificados utilizando 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 cuadros u otros gráficos de visualización de datos.
Algunas aplicaciones científicas no proporcionan la función de salvapantallas (o dejan de proporcionar imágenes de salvapantallas 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 tiene características que pueden hacerlo 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 aficionados que compiten con otros por el estatus dentro de la subcultura de crédito BOINC.
^ "Tecnología cliente-servidor BOINC | Semantic Scholar". www.semanticscholar.org . Consultado el 14 de agosto de 2022 .
^ La transición de SETI @ home a BOINC
^ Anderson, David P.; McLeod, John (2007). "Programación local para informática voluntaria". 2007 Simposio internacional de procesamiento distribuido y paralelo del IEEE . págs. 1–8. doi :10.1109/IPDPS.2007.370667. ISBN978-1-4244-0909-9. S2CID 15164675.
