Los comienzos: el proyecto SETI
SETI (Search for ExtraTerrestrial Intelligence) es el nombre por el que se conoce a las actividades que se llevan a cabo para la búsqueda de inteligencia extraterrestre, que empiezan tan temprano como en 1960, con el Proyecto Ozma. Esta búsqueda se hace generalmente analizando las emisiones de radio que llegan a la Tierra en busca de patrones que indiquen que dichas emisiones son de origen artificial.

Idealmente, una búsqueda exhaustiva debería analizar todo el firmamento visible desde la Tierra y barrer todas las frecuencias durante el mayor tiempo posible. Sin embargo el análisis es muy costoso y exige de grandes recursos, sobre todo desde el punto de vista computacional. Por ello las labores de búsqueda son limitadas, a ciertos sectores del cielo, a ciertas frecuencias, con patrones concretos, etc.

En este contexto nace, en 1999, el proyecto SETI@home (que podemos traducir como “búsqueda de vida extraterrestre en casa”). Auspiciado por la Universidad de Berkeley en California, este proyecto recoge escuchas de distintas frecuencias a través del radiotelescopio de Arecibo en Puerto Rico y después las procesa en busca de señales que puedan corresponder a un origen inteligente. Para llevar a cabo dicho procesado usa un enfoque novedoso para la época: En vez de usar computadores de mayor o menor potencia dedicados exclusivamente a tal tarea, SETI@home utiliza la computación voluntaria distribuida.

La computación voluntaria funciona sobre la base de que los usuarios de computadores personales, de forma voluntaria, ceden parte de los recursos de su computador para llevar a cabo cálculos que el proyecto necesita. SETI@home tenía un programa cliente diseñado específicamente para tal tarea que cualquiera podía instalar en su PC. El cliente se conectaba periódicamente a través de internet a un servidor situado en la Universidad de Berkeley, solicitaba un paquete de datos, lo descargaba en el computador del voluntario, lo analizaba y devolvía los resultados al servidor, repitiendo el proceso una y otra vez.

Para hacer los cálculos más interesantes y motivar a los voluntarios, el cliente de SETI@home podía mostrar en pantalla una representación gráfica de la señal a medida que ésta se analizaba. Además se llevaba la cuenta de cuantos datos había calculado cada voluntario y se confeccionaban listas de posiciones, fomentando la competición. La respuesta de la comunidad de internautas es muy grande, y con el tiempo llegan a ser más de un millón los que se adhieren al proyecto.

Características principales de BOINC
El sistema cliente / servidor de SETI@home es innovador, pero adolece de ciertos problemas. Es específico de un proyecto concreto, y funciones tales como la gestión de la seguridad son mejorables (falsificación de resultados por parte de los clientes). Sin embargo, desde el punto de vista técnico y popular (aunque el proyecto en sí no haya detectado nada relevante hasta la fecha), es un éxito y se identifican otros proyectos con altos requisitos de cálculo que podrían beneficiarse de la computación voluntaria.

Con el tiempo el software de SETI@home evoluciona y da lugar en el año 2002 a un sistema genérico llamado BOINC (Berkeley Open Infrastructure for Network Computing). Este sistema, aprendiendo de los errores cometidos con SETI@home, es mucho más flexible y seguro, y dota a cualquiera con las herramientas necesarias para llevar a cabo computación distribuida (gestión de clientes, servidores, tareas, resultados, etc.), con lo que cualquier proyecto puede usar BOINC, configurarlo según sus necesidades, y usarlo para sus tareas de cálculo. Destacamos, entre otras muchas, su:

Estructura de un proyecto BOINC
Las comunicaciones se basan en el modelo cliente-servidor:

En el servidor están alojados proyectos. Cada proyecto puede tener varias aplicaciones. Las aplicaciones se pueden desarrollar para distintas plataformas y ser versionadas. Para cada aplicación se generan trabajos los cuales deben ser ejecutados por los clientes y generar los resultados. El servidor tiene una serie de aplicaciones en ejecución para automatizar el proceso. También tiene varias tareas programadas para tener actualizados la base de datos, usuarios, etc.
En la operativa normal el cliente pregunta al servidor si hay tareas pendientes. Si las hay, dicho cliente descarga los archivos necesarios, ejecuta la tarea y reporta el resultado. El cliente tiene un tiempo límite para reportar el resultado. Si no lo hace a tiempo, el servidor manda la tarea a otro cliente. Una vez que el servidor tiene el resultado, lo evalúa.

Podemos configurar una cantidad innumerable de cosas, como a cuantos clientes se manda el mismo trabajo (redundancia), la cantidad de resultados que debemos tener iguales para considerarlo válido, el tiempo límite que tiene el cliente para reportar el resultado, la cantidad de tiempo cpu y memoria de que dispone el cliente para la tarea, etc.

En cuanto a la seguridad, cada proyecto tiene dos claves, una pública en el cliente, y otra privada en el servidor, de forma que se puede asegurar que nos estamos uniendo al verdadero proyecto. Además, todos los archivos que se descarga el cliente se envían con firma digital.
Participar en un proyecto BOINC es muy sencillo. Simplemente hay que descargarse el software de la página oficial de BOINC e instalarlo. Después, el cliente puede elegir en que proyectos le interesa unirse, o por el contrario, unirse a un administrador de proyectos. En vez de ser el usuario quien elija los proyectos, es el administrador de proyectos quien hace estas gestiones, y lo comunica a los clientes. Hay varias plataformas para este cometido, entre ellas, Jarifa, GridRepublic.

Limitaciones de BOINC
Posiblemente el principal problema de BOINC es su gran complejidad, y el esfuerzo, tiempo, medios y conocimientos que se requieren para configurar adecuadamente, mantener y utilizar BOINC como plataforma de proyectos. Esto es algo inherente a cualquier sistema con las características de BOINC: gran envergadura, multiplataforma y de código abierto, pensado y hecho por ingenieros para ingenieros. Esto solo se puede combatir con formación y aprendizaje.

El segundo problema es que BOINC es muy adecuado para el objeto con que fue creado, que es distribuir tareas para ser calculadas de forma anónima a gran cantidad de clientes que han decidido suscribirse a un proyecto determinado. Sin embargo, y pensando en proyectos de pequeña y mediana envergadura (por ejemplo, un laboratorio, universidad o empresa que disponen de su propio servidor de proyectos BOINC y quieren utilizar sus propios computadores como clientes), algunas tareas que no tienen sentido en un contexto de computación voluntaria y anónima sí lo tienen ahora.

Por ejemplo, en un proyecto BOINC es el voluntario el que decide a qué proyecto suscribirse para donarle su capacidad de cálculo. En un entorno cerrado sin embargo, es muy práctico poder hacerlo al revés, es decir, dejar al servidor que decida él a qué proyectos y en qué medida va a colaborar cada uno de los clientes. Así un centro de cálculo que provea con servicios de computación a distintos proyectos podría decidir en función de las necesidades a qué proyecto dedicar qué cantidad de recursos. Pensemos además en una institución que tenga varios cientos de computadores disponibles (por ejemplo en horario nocturno). Sería interesante poder encenderlos cuando fuera necesario y apagarlos a voluntad una vez realizada su labor.

Nada de esto es posible directamente con BOINC (o al menos no de una manera sencilla), y es por eso que se hace necesario en ocasiones el uso de herramientas de terceros que complementen y en algunos casos mejoren su funcionalidad.