Resumo

  • A versão 5.0 do cliente, em 2004, introduziu servidores de coleta para receber resultados quando o servidor de origem estivesse inacessível.
  • Receber, conferir, contabilizar e encaminhar as contribuições exigia infraestrutura própria; um relato de junho de 2009 mostra a equipe cuidando dela sob pressão.

Doar o tempo ocioso do computador parece uma troca simples. A máquina faz contas, a ciência ganha resultados e o voluntário pode conferir sua contribuição. Só falta combinar com quem vai receber.

O Folding@home nasceu em outubro de 2000 no laboratório de Vijay Pande na Stanford University, segundo a linha do tempo do projeto. O participante instalava um programa que buscava tarefas de simulação molecular, executava o cálculo e devolvia o resultado. Continuava sendo o dono do computador, da conexão e do botão de desligar.

O retorno podia dar trabalho mesmo depois de a máquina cumprir sua parte. Para a pesquisa, uma conta pronta precisava atravessar a rede e chegar ao lugar certo.

Uma portaria para o trabalho concluído

O artigo de arquitetura de 2009 registra a solução adicionada em 2004, com o cliente 5.0: servidores de coleta.

Em condições normais, o resultado voltava ao servidor de trabalho que havia distribuído a tarefa. Se ele estivesse inacessível, o cliente poderia entregar a um servidor de coleta designado. Este conferia a tarefa nos registros de trabalho emitido, aceitava o resultado e atribuía o crédito. Depois, encaminhava o material quando o destinatário original estivesse disponível.

Enquanto isso, o cliente podia pedir nova tarefa a um servidor de trabalho ativo. A espera passava a ocorrer dentro do projeto. O voluntário deixava de depender da recuperação daquele destinatário específico para continuar contribuindo.

Também diminuía a fila que aguardava o servidor consertado. Receber uma avalanche de conexões logo após voltar ao ar é um jeito especialmente mal-educado de dar boas-vindas. A equipe de manutenção tinha motivos para preferir uma recepção mais calma.

Quem cuida da portaria

Em 16 de junho de 2009, Pande descreveu uma situação bastante concreta. Um servidor GPU havia sofrido uma pane grave e não encontrava sua partição raiz. Outros dois tinham caído por excesso de carga, mas já estavam funcionando novamente. O pessoal tentava implantar a infraestrutura nova ao mesmo tempo que mantinha a antiga e estava sobrecarregado.

Servidores de coleta mais funcionais estavam entre os benefícios esperados da atualização. O mesmo valia para servidores de trabalho que precisassem de menos reinicializações sob carga. As panes atrapalhavam a implantação. Ter um destino alternativo criava mais uma tarefa permanente de operação.

O artigo técnico descreve participantes que pagavam pela quantidade de dados transmitidos, usavam modem ou ajustavam o consumo de CPU. Menciona também os pontos de usuários e equipes e a ajuda voluntária nos fóruns. Por trás da capacidade agregada havia gente administrando custos, expectativas e dúvidas.

Contabilizar a entrega tornava a contribuição visível. Guardar e encaminhar o resultado permitia aproveitá-la. Ao concluir o artigo, os autores identificavam no recebimento, armazenamento e processamento dos resultados o limite para acrescentar mais clientes.

A campanha podia conseguir mais computadores. A portaria precisava dar conta das encomendas que eles já tinham terminado.