Diferentemente de uma arquitetura Cliente-Servidor, em que cada parte desempenha um papel bem definido, em um sistema P2P os pares desempenham tanto o papel de cliente quanto de servidor de dados[1]. Esta característica dos sistemas P2P permitem a implementação de aplicações naturalmente escaláveis, e de grande disponibilidade.
A escalabilidade em sistemas P2P deve-se a contribuição de cada par ao sistema, em termos de processamento e capacidade de armazenamento. Ou seja, quando um par junta-se ao sistema ele deve também desempenhar o papel de servidor, e por isso irá contribuir com uma certa capacidade de armazenamento de informação e de processamento. Ao desempenhar um papel duplo no sistema, os pares compartilham a responsabilidade pelo armazenamento e disponibilização da informação. Dessa forma, se um par falhar os demais devem manter o sistema em funcionamento.
A descentralização dos sistemas P2P mostra-se muito mais vantajosa frente a abordagem Cliente-Servidor. Aplicações Cliente-Servidor estão baseadas em um único ponto (o servidor), que se não estiver disponível comprometerá toda a aplicação. Além disso, o aumento no número de usuário do sistema impõe maior demanda sobre o servidor, requerem para viabilização da aplicação um aumento em sua capacidade de processamento.
A despeito dos benefícios da escalabilidade e disponibilidade, a implementação de sistemas P2P é tarefa desafiadora pois, na ausência de uma figura centralizadora, um par que chega ao sistema deve: i) adquirir um identificador global, ii) se utilizar de mecanismo para localização de pares correspondente, e iii) empregar um método que garanta a manutenção de conexões estabelecidas. Tais eventos caracterizam o Problema de Bootstrap.
Em sistemas P2P de grande porte, com várias dezenas de milhares de pares, os mantenedores desses sistemas têm contornado o problema de bootstrap com a utilização de servidores centrais. Essa é uma solução simples mas que apresenta um custo justificando apenas pela escala dos sistemas em questão. Ou seja, na ausência desses servidores e de um protocolo para solução do bootstrap, aos usuários caberia a resolução do problema, algo que está além do alcance dos usuários casuais.
Por outro lado, em sistemas de pequeno porte, com dezenas de nós, a utilização de servidores centrais se inviabiliza devido o custo envolvido em suas implementações, i.e, a manutenção de um servidor em atividade contínua representam um alto custo para a escala do sistema em questão. Além disso, esse servidor representar um ponto único de falha[2][3], i.e caso ele esteja indisponível todo o sistema estará comprometido.
Na impossibilidade de utilização de servidores, o problema de Bootstrap em sistemas P2P de pequeno porte requer a utilização de um protocolo que permitisse ao par: i) implementar o procedimento de Reflexão; ii) implementar o procedimento de Rendezvous; e, finalmente, iii) implementar o procedimento de Relaying.
|
