1-HOP routing 1 ricardo.pereira@inesc-id.pt IST 2-11-2009 1 Imagens retiradas de One Hop Lookups for Peer-to-Peer Overlays por Anjali Gupta, Barbara Liskov, Rodrigo Rodrigues ou When Multi-Hop Peer-to-Peer Routing Matters por Rodrigo Rodrigues, Charles Blake
1 2 Falhas 3
Características dos DHTs estudados Vantagens Desvantagens Routing com número de hops previsível e limitado (probabilisticamente) Tabela de routing ocupa pouca memória Churn com impacto reduzido nas tabelas de routing Routing no overlay resulta sempre em atraso superior ao routing na Internet Protocolos com alguma complexidade
Questão Como podemos evitar multi-hop routing?
Evitar atraso do multi-hop Atraso pode ter impacto signicativo em alguns tipos de aplicações (ex: sistemas de cheiros distribuídos) Para evitar este atraso, será necessário cada nó conhecer todos os outros nós da rede
Questão Quais os factores limitativos desta solução?
Falhas Noticar ecientemente, a todos os nós, todos os eventos de entrada e saída Manter uma vista razoávelmente actualizada do sistema em cada nó Consumir uma quantidade razoável de largura de banda Conseguir atingir uma elevada parte dos nós à primeira tentativa Desao: Estudo coloca o tempo médio de uma sessão Gnutella nas 2,9 horas. Para um sistema com 1,000,000 de nós, isto corresponde a cerca de 190 entradas ou saídas por segundo (assumindo tamanho constante)
Falhas Espaço de identicadores idêntico para nós e objectos Espaço circular de 128 bit, módulo 2 128. Anel Cada nó mantém ponteiro para sucessor e antecessor Nós uniformemente distribuídos (id aleatório ou função de hash) Cada nó conhece todos os outros Objecto guardado no nó sucessor da chave Espaço de identicadores dividido em fatias (slice), que são por sua vez dividadas em unidades (unit). Tudo de tamanho constante A cada nível, existe um líder, que é o nó sucessor do meio desse espaço
Falhas Árvore de disseminação: estrutura sobreposta à rede overlay Nó que detecta evento comunica-o ao líder da sua fatia Líderes agregam eventos e periódicamente comunicam-nos a todos os outros líderes de fatia Líderes de fatia comunicam periódicamente os eventos a todos os seus líderes de unidade Líderes de unidade comunicam eventos ao seu sucessor e antecessor. Estes continuam a propagar o evento numa única direcção. Não há propagação para além da fatia Não há redundância de mensagens
Tempo de propagação Falhas Slice leaders comunicam com cada um dos outros a intervalos de t_big, desfasados para cada slide leader Slice leaders comunicam com unit leaders a cada t_wait t_small é tempo esperado de propagação dentro da unit t_detect é tempo que demora detecção e comunicação do evento No pior dos casos, evento demora t_detect + t_big + t_wait + t_small a ser propagado a todos os nós
Custo de propagação das mensagens Falhas Líder de fatia é nó com maior esforço Tráfego reduzido através de agregação das mensagens, uso de árvore onde não há redundância e piggy-back nas mensagens de keep-alive no caso dos nós normais Assume que 99% das queries devem funcionar à primeira Dimensões optimizadas para cada tamanho de rede
Custo por tipo de nó Falhas k - número de slices u - número de units por slice m - Bytes por evento v - overhead por mensagem r - eventos / segundo
Detecção de falhas Falhas Cada nó contacta periódicamente o sucessor e antecessor Após detectar a falha notica slice leader Se falha é slice leader ou unit leader, o sucessor toma o seu lugar Novo slice leader contacta com slice leaders e seus unit leaders para actualizar dados Novo unit leader contacta com slice leader para actualizar dados
Contornar falhas Falhas Se uma query do nó A para o B falhar por B ter saído, nó envia query ao sucessor de B Se query falhar por haver um novo nó (C) antes de B, responsável pelos valores, B comunica o facto a A, que realiza nova query a C Fracção de queries falhadas é: r t_total n
Escalabilidade Falhas Slice leaders são o bottleneck do sistema devido à largura de banda exigida Pode ser criado segundo anel, apenas com nós mais capazes Líderes são escolhidos desse anel Tem de haver um número razoável de supernós para garantir alguns por slice
Premissas Protocolo básico. Cada nó avisa todos os outros Análise restrita a sistema de cheiros distribuído Cada cheiro replicado em 8 nós Upload limitado a 200Kbps (cable modem à data do estudo) Não queremos usar mais de 25% do upload com o protocolo
Custo de manter réplicas
Custos de manter réplicas e tabela com todos os nós
Evolução do hardware Espaço de disco evoluiu muito mais rapidamente que velocidade de upload (8000x vs. 50x) Para partilhar mais disco é necessário car mais tempo online Estabilidade acrescida torna sistema 1-hop mais atractivo
Fim Dúvidas?