Simulando falha de nó em um DHT

Question

Atualmente estou fazendo alguns testes de desempenho com o DHT de pastelaria grátis.Freepastry é um DHT de código aberto feito em Java.

O objetivo é monitorar o efeito no DHT quando um certo número de nós fica inativo.Meu problema é que não tenho certeza da melhor maneira de eliminar nós.No momento, cada nó está rodando em uma porta diferente da minha máquina.Estou destruindo esses nós usando o método destroy() da API Pastry http://www.freepastry.org/FreePastry/javadoc21a3/rice/pastry/PastryNode.html#destroy()

Estou preocupado que isso possa ser irreal na simulação de falha de nó e se devo eliminar os nós de uma maneira diferente, como usando tcpkill?

Estou executando o Mac OS X snow leopard e gostaria de ouvir alguma sugestão?

Answer 1

Existem diferentes formas de falhas de nós.

O mais comum é simplesmente o nó ficar offline porque o aplicativo que está executando o DHT foi desligado.

A alteração de um IP dinâmico de uma conexão doméstica à Internet tem essencialmente um efeito sutilmente diferente, pois invalida todas as entradas existentes na tabela de roteamento sobre ela, mas a contagem geral de nós não diminui.Você perde um e ganha um novo.

Outro problema comum são os problemas de acessibilidade devido aos NATs.A visibilidade desse nó pode depender do tipo de NAT e se você teve contato recente com ele.

Os efeitos resultantes da rotatividade podem, na verdade, ser bastante complexos.Em primeiro lugar, o tempo de atividade dos nós individuais geralmente segue uma distribuição exponencial.Muitos estão disponíveis apenas por um curto período de tempo e poucos permanecem estáveis ​​por dias ou meses.

Suponha que você tenha um núcleo estável de nós de vida moderada a longa que, na verdade, constituem 90% da rede.10% dos mesmos nós aparecendo e desaparecendo constantemente causarão algum tráfego indireto, mas não prejudicarão muito a rede.Você tem muita rotatividade, mas pouco impacto.

Se 10% da população de nós ficar off-line após 10 minutos e for substituída por um conjunto totalmente novo de nós do pool inativo, você estará perdendo essencialmente 10% de sua redundância a cada 10 minutos.Se a replicação de dados entre nós não acompanhar isso ou nem existir, seus dados irão decair exponencialmente.Você também tem muita rotatividade, mas um impacto enorme.

Nem tenho certeza de que tipo de simulação refletiria a realidade da melhor maneira.Acho que a restrição mais realista é simplesmente ter um conjunto fixo de potencial nós.São computadores que possuem a implementação DHT instalada.

Cada nó teria então um perfil de tempo, quanto tempo permanece ativo em média e quanto tempo permanecerá inativo em média (onde esses dois parâmetros estão parcialmente correlacionados entre si.nós com tempo de atividade longo geralmente não têm tempos de inatividade muito longos, pois provavelmente estão sempre ativos).E cada nó atua nesses parâmetros de forma independente.Na realidade, a hora do dia também desempenha um papel, como pode ser facilmente visto aqui: http://dsn.tm.uni-karlsruhe.de/english/2936.php

Então...Resumindo, apenas executar e eliminar alguns nós aleatoriamente não fornecerá um resultado realista sobre a resiliência de um DHT, pois o impacto variará amplamente.

Quanto à parte técnica, você provavelmente desejará executar todos eles na mesma VM java e usar E/S multithreading ou sem bloqueio para reduzir a sobrecarga de execução de cada instância em uma VM separada.Isso também permitiria que você agendasse seus tempos de atividade e inatividade de uma maneira mais realista.

Como você pode atribuir vários IPs a um único computador, você poderá executar centenas de milhares de nós em um computador simplesmente com base na contagem de IP/portas.Mas o consumo de recursos do processo acabará paralisando até mesmo o sistema mais rápido, já que muito poucas implementações de DHT são realmente implementadas para escalar tão bem.

Portanto, você provavelmente precisará executar isso em uma rede com alguns milhares de nós por computador para obter algo próximo do realista.

Ou isso ou você recorre a mais simulações matemáticas em vez de executar implementações reais.