Tecnología cliente-servidor BOINC

Tecnología cliente-servidor BOINC
BOINC Logo custom.png

Tecnología cliente-servidor BOINC, del Inglés BOINC client–server technology, se refiere al modelo de como funciona BOINC. La infraestructura de BOINC consiste de dos capaz que operan bajo la arquitectura cliente-servidor. Una vez que el software BOINC es instalado en un computador, el servidor empieza a enviar tareas al cliente. Las operaciones son ejecutadas en el lado del cliente y los resultados son subidas al servidor.

Contenido

Diseño y estructura de BOINC

  • BOINC es diseñado como una estructura libre para cualquiera que desee crear un proyecto de computación distribuida.
  • BOINC consiste de un sistema servidor y un software cleinte que se comunican entre ellos para distribuir, procesar, y retornar unidades de trabajo (workunits).

Estructura del Servidor

Una parte importante de BOINC es el servidor. El servidor puede correr en una o varias maquinas para permitir que BOINC sea fácilmente escalable a proyectos de cualquier tamaño. Los servidores BOINC corren en Linux y usan Apache, PHP, y MySQL como base para las paginas web y bases de datos.

Los cómputos científicos corren en los computadores de los participantes y los resultados son analizados después de que éstos sean subidos desde el PC del usuario a la base de datos del investigador científico para luego ser validados por el servidor. El proceso de validación involucra correr todas las tareas en múltiples PCs de contribuyentes y comparar los resultados.

Los servidores BOINC proporcionan las siguientes características:

  • redundancia homogénea (homogeneous redundancy) (enviar workunits sólo a computadores de la misma plataforma -- por ej: Sólo Windows XP SP2.
  • goteo de workunits (workunit trickling) (enviar información sobre una workunit antes que ésta termine)
  • planificación local (locality scheduling) (enviar workunits a computadores que ya tienen los archivos necesarios y crear trabajo en tiempo real)
  • distribución de trabajo basado en los parámetros del computador (work distribution based on host parameters) (workunits que requieran 512 MB de RAM, por ejemplo, sólo serán enviadas a computadores que contengan al menos esta cantidad de RAM[1] )

Los servidores consisten de dos programas CGI y (normalmente) cinco daemons, escritos en C++. Los cómputos por hacerse por un cliente son llamas workunits. Un resultado describe una muestra de una workunit, aun cuando ésta no esté terminada. Un proyecto no crea resultados explícitamente; el servidor los crea automáticamente de las workunits.

El programa planificador CGI maneja los pedidos de los clientes, reciviendo resultados terminados y enviando trabajo nuevo par ser procesado. El planificador no recibe las tareas directamente de la base de datos. En vez de eso, hay un daemon alimentador (feeder) que carga tareas de la base de datos, y los mantiene en un bloque de memoria compartida, que el planificador lee. El alimentador periodicamente llena estos "espacios" vacíos en la memoria compartida despues que el planificador envia resultados a un cliente.

Cuando todos los resultados de una workunit están completos y retornados, el validador (validator) los compara. El validador puede tener codigo personalizado para hacer comparaciones difusas entre los resultados. Si los resultados son iguales, la workunit es marcada como validada, los usuarios son otorgados créditos por ello, y un "resultado canónico" es elegido.

Luego, el daemon asimilador (assimilator) procesa el resultado canónico usando 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 a algún otro lugar. Un asimilador puede también generar más workunits basada en la data retornada.

El daemon borrador_de_archivo (file_deleter) borra los archivos de salida después de que el asimilador los haya procesado, y borra los archivos de entrada que ya no se necesiten.

Debilidades en el diseño del servidor

Despliegue de Servidor

  • El Servidor BOINC está solo diseñado para ser desplegado en Unix, o en sistemas Unix-like.
  • Los Servidores BOINC no son tan simple para desplegar como el Cliente BOINC ya que son basados en un gran número de scripts.
  • La página web del proyecto Servidor BOINC hace un muy mal trabajo en almacenar bases de datos compilados de scripts del lado del servidor para llos que quieran crear un proyecto BOINC.
  • El Servidor BOINC puede ser desplegado en sistemas Windows XP y Windows Vista (ya que son POSIX) pero la estructura de diseño de Windows hace esto difícil y más caro que simplemente ocupar Linux.
  • Los Servidores BOINC usan PHP y MySQL como su base de tecnologías -- estas aplicaciones son susceptibles a correr mal en servidores de poco mantenimiento.

Estructura del cliente

Foto del BOINC Manager administrando un cliente BOINC.

El Cliente BOINC está estructurado en un número de aplicaciones separadas. Estos se intercomunican con el mecanismo llamada a procedimiento remoto (RPC) de BOINC.

Estas aplicaciones son:

  • El programa boinc (o boinc.exe). El cliente núcleo.
  • El cliente núcleo es un proceso que:
    • Mantiene la comunicación entre el cliente y el servidor.
    • Descarga las aplicaciones científicas, proporciona un mecanismo de registro unificado, asegura que los binarios de las aplicaciones científicas esten actualizadas, y planifica los recursos de la CPU entre las aplicaciones científicas (si es que más de una está instalada).
    • Aun cuando el cliente núcleo es capaz de descargar nuevas aplicaciones científicas, éste no puede actualizarse él mismo. Los autores de BOINC encontraron que hacerlo capaz de actualizarse solo podria ser una amenaza a la seguridad, además de todos los riesgo que conllevan las actualizaciones automáticas.
    • En Unix, el cliente núcleo corre generalmente como un daemon (o ocasionalmente como un trabajo cron).
    • En Windows, BOINC inicialmente no fue un servicio Windows, pero simplemente una aplicación ordinaria. El Cliente BOINC para Windows, versión 5.2.13 y más arriba añaden, durante la instalación, la opción de "Service Installation" (Instalación de Servicio).
    • Dependiendo como el Cliente BOINC fue instalado, éste puede puede correr en el background (en un segundo plano) como un daemon, o empezar a correr cuando el usuario inicia sesión (y es parada cuando el usuario se sale del sistema). La versión del software de gestión y manejo de workunits otorgado por el cliente núcleo simplifica inmensamente la codificación de las aplicaciones científicas.
  • boincmgr (o boincmgr.exe). Un GUI que se comunica con la aplicación núcleo usando llamadas a procedimiento remoto. Por defecto un cliente núcleo solo permite comunicaciones desde el mismo computador, pero puede ser configurado para permitir conecciones de otros computadores (opcionalmente ocupando autenticación con contraseña); este mecanismo permite administrar una granja de instalaciones BOINC desde sólo una estación de trabajo. Una inconveniencia de usar el mecanismo RPC es que ocasionalmente se considera un riesgo para la seguridad, administrando una ruta para los hackers.
  • El protector de pantalla de BOINC. Este proporciona un framework por donde las aplicaciones científicas pueden mostar los gráficos en la ventana del protector de pantalla del usuario. Los protectores de pantalla de BOINC son escritos usando el BOINC graphics API, OpenGL y las utilidades GLUT. Típicamente, los protectores de pantalla de BOINC muestran gráficas animadas detallando el trabajo en proceso.
  • Algunas aplicaciones científicas no proveen un protector de pantalla (o dejan de proveer imágenes para el protector de pantalla cuando éstas estén paradas). En estas circunstancias el protector de pantalla muestra un logo pequeño de BOINC tambaleándose por la pantalla.

Una red BOINC es similar a un botnet de Hackers/Spammers. Sin embargo, en el caso de BOINC, es esperado que el software sea instalado y operado con el consentimiento del dueño del computador.

Como BOINC tiene características que lo pueden hacer invisible al usuario típico, existe un riesgo de instalaciones inautorizadas y difíciles de detectar. Esto podria ayudar a la acomulación de créditos BOINC para aficionados que compiten con otros por estatus dentro de la subcultura créditos BOINC dentro de la comunidad BOINC.

Referencias

Véase también


Wikimedia foundation. 2010.

Игры ⚽ Нужен реферат?

Mira otros diccionarios:

Compartir el artículo y extractos

Link directo
Do a right-click on the link above
and select “Copy Link”