Estructura cliente-servidor de computación voluntaria BOINC
Diagrama visual de la estructura cliente-servidor de BOINC
La tecnología cliente-servidor BOINC [1] 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 del 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 libre para cualquiera que desee iniciar un proyecto de computación distribuida.
BOINC consta de un sistema servidor y un software 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 se adapte 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 base de datos .
Los cálculos científicos se ejecutan en las computadoras de los participantes. Después de cargar los datos 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 computadoras 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 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 localidades (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 en función de 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 daemons , escritos en C++ . Los cálculos que deben realizar los clientes se denominan workunits . Un resultado describe una instancia de una workunit, incluso si no se ha completado. Un proyecto no crea resultados de forma explícita; el servidor los crea automáticamente a partir de workunits.
El programa CGI del planificador maneja las solicitudes de los clientes, recibe los resultados completados y envía nuevos trabajos para su procesamiento. El planificador no obtiene los resultados disponibles directamente de la base de datos. En su lugar, un demonio alimentador carga las tareas de la base de datos y las guarda en un bloque de memoria compartida , que el planificador lee. El alimentador llena 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 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 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, se les otorga crédito a los usuarios que devolvieron resultados legítimos y se elige un "resultado canónico". Si los resultados no concuerdan, 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 encuentra un quórum de resultados coincidentes o se alcanza un límite en la cantidad 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, mientras que 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 de las unidades de trabajo cuando se crean por primera vez y cuando se necesitan más (por ejemplo, si un resultado resulta no ser válido).
BOINC en el cliente está estructurado en varias aplicaciones independientes que 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.
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 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 por sí solo. Los autores de BOINC consideraron que hacerlo planteaba un riesgo de seguridad inaceptable [ cita requerida ] , así como todos los riesgos que tienen los procedimientos de actualización automática en informática.
En Unix , el cliente principal generalmente se ejecuta como un demonio (o en ocasiones como un trabajo cron ).
En Windows, BOINC no era inicialmente un servicio de Windows, sino una aplicación normal. El Cliente BOINC para Windows, versiones 5.2.13 y superiores, añade durante la instalación la opción de "Instalación del servicio".
Según cómo se haya instalado el software cliente de BOINC, 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 de software y el manejo de unidades de trabajo que ofrece el cliente principal simplifican enormemente la codificación de aplicaciones científicas.
Una o varias aplicaciones científicas. Las aplicaciones científicas realizan los cálculos científicos básicos. 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 interfaz gráfica de usuario que se comunica con la aplicación principal mediante llamadas a procedimientos remotos . De forma predeterminada, un cliente principal solo permite conexiones desde la misma computadora, pero se puede configurar para permitir conexiones desde otras computadoras (opcionalmente mediante autenticación por contraseña); este mecanismo permite que una persona administre una granja de instalaciones BOINC desde una única estación de trabajo. Una desventaja del uso de mecanismos RPC es que a menudo se los considera riesgos de seguridad porque pueden ser la ruta por la que los piratas informáticos pueden invadir las computadoras seleccionadas (incluso si están configuradas para conexiones desde la misma computadora).
La interfaz gráfica de usuario está escrita 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, pueden indicarles 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 . Proporciona un marco mediante el cual las aplicaciones científicas pueden mostrar gráficos en la ventana del salvapantallas del usuario. Los salvapantallas BOINC se codifican utilizando la API de gráficos BOINC, OpenGL y el kit de herramientas GLUT . Normalmente, los salvapantallas BOINC muestran gráficos animados que detallan el trabajo en curso, tal vez mostrando gráficos o diagramas 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 ofrecer imágenes de protector de pantalla cuando están inactivas). En estas circunstancias, el protector de pantalla muestra un pequeño logotipo de 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 aficionados que compiten con otros por el estatus dentro de la subcultura de los créditos 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 computación voluntaria". Simposio internacional IEEE sobre procesamiento paralelo y distribuido de 2007. págs. 1–8. doi :10.1109/IPDPS.2007.370667. ISBN978-1-4244-0909-9.S2CID15164675 .
