BitTorrent usa DHT?

Resumo

BitTorrent é um protocolo ponto a ponto projetado para transferência de arquivos. Ele permite que os usuários se conectem diretamente entre si para enviar e receber partes do arquivo. O protocolo utiliza um servidor central chamado de rastreador para coordenar as ações de todos os pares envolvidos. No entanto, o BitTorrent também inclui uma extensão chamada protocolo de tabela de hash desleixado (DHT) distribuída, que é um protocolo de rastreador de ponto a ponto baseado em UDP.

Pontos chave

  • BitTorrent é um protocolo para transferir arquivos.
  • Os usuários se conectam diretamente para enviar e receber partes do arquivo.
  • O protocolo usa um servidor central chamado de rastreador.
  • O rastreador coordena as ações dos pares envolvidos.
  • O protocolo DHT é uma extensão para BitTorrent.
  • DHT é um protocolo rastreador de ponto a ponto baseado em UDP.
  • BitTorrent usa o TCP como seu protocolo de transporte.
  • A conhecida porta TCP para tráfego de bittorrent é 6881-6889.
  • O DHT usa várias portas UDP negociadas pelos colegas.
  • BitTorrent tem sido amplamente adotado desde sua criação em 2002.

Perguntas e respostas


P: Como o BitTorrent funciona?

R: BitTorrent é um protocolo ponto a ponto que permite aos usuários transferir arquivos se conectando diretamente entre si. Em vez de confiar em um servidor central, o BitTorrent utiliza um rastreador para coordenar as ações dos pares envolvidos na transferência de arquivo. Essa abordagem descentralizada permite uma distribuição eficiente de arquivos, pois os usuários podem compartilhar partes do arquivo que eles já baixaram com outras pessoas.


P: Qual é o objetivo do protocolo DHT em BitTorrent?

R: O protocolo DHT, ou protocolo de tabela de hash desleixado distribuído, é uma extensão para BitTorrent. Ele permite torrents sem rastrear armazenando informações de contato de pares em uma tabela de hash distribuída. Cada par da rede se torna um rastreador e o protocolo é implementado sobre UDP. O DHT permite que os colegas encontrem e se conectem sem confiar em um servidor de rastreador central.


P: Qual protocolo de transporte BitTorrent usa principalmente?

R: O BitTorrent usa principalmente o TCP (Protocolo de Controle de Transmissão) como seu protocolo de transporte. O TCP garante a entrega confiável e ordenada de pacotes de dados entre pares. A linha de porta TCP bem conhecida para o tráfego de BitTorrent é 6881-6889.


P: O protocolo DHT usa UDP ou TCP?

R: O protocolo DHT no BitTorrent usa UDP (Protocolo de Datagrama do Usuário) como seu protocolo de transporte. UDP é um protocolo sem conexão que fornece entrega mais rápida e menos confiável de pacotes em comparação com o TCP. Os pares envolvidos no protocolo DHT negociam portas UDP para estabelecer conexões.


P: Quando o BitTorrent foi criado?

R: BitTorrent foi projetado por Bram Cohen em abril de 2001 e implementado no verão de 2002. Foi o primeiro programa a usar o protocolo BitTorrent e, desde então, muitas aplicações foram desenvolvidas com base no protocolo.


P: Qual é o papel do rastreador em BitTorrent?

R: O rastreador em BitTorrent é um servidor central que gerencia conexões entre pares. Ele mantém o controle de quais colegas possuem as diferentes partes de um arquivo e facilita a troca de dados entre eles. No entanto, o rastreador não tem conhecimento do conteúdo real do arquivo sendo distribuído.


P: Existem números de porta específicos associados ao tráfego BitTorrent?

R: Sim, a bem conhecida linha de porta TCP para o tráfego BitTorrent é 6881-6889. Essas portas são usadas para estabelecer conexões TCP entre pares. Além disso, as portas UDP usadas para o protocolo DHT são negociadas pelos pares envolvidos na comunicação.


P: Qual é a diferença entre um par e um nó em BitTorrent?

R: No contexto do BitTorrent, um colega refere -se a um cliente ou servidor que ouve uma porta TCP e implementa o protocolo BitTorrent para transferência de arquivos. Por outro lado, um nó refere -se a um cliente ou servidor que ouve em uma porta UDP e implementa o protocolo de tabela de hash distribuídos (DHT). Os nós são usados ​​para armazenar e recuperar informações de contato de pares para torrents sem rastrear.


P: O Wireshark é capaz de analisar o tráfego BitTorrent?

R: Sim, o Wireshark inclui um dissector BitTorrent totalmente funcional que pode analisar e decodificar o tráfego do BitTorrent. As extensões DHT e UTP também são suportadas pelo Wireshark. O dissector BitTorrent está disponível desde uma versão específica do Wireshark (detalhes não fornecidos).


P: Existem configurações de preferência relacionadas ao BitTorrent no Wireshark?

R: Sim, existem configurações de preferência no Wireshark relacionadas ao BitTorrent. Algumas dessas configurações incluem a capacidade de remontar mensagens BitTorrent, abrangendo vários segmentos TCP e a opção de decodificar o peer_id das mensagens de handshake. Essas configurações de preferência fornecem uma análise mais detalhada do tráfego BitTorrent capturado no Wireshark.


P: Você pode fornecer um exemplo de captura de arquivo de tráfego BitTorrent?

R: Sim, existem exemplo de captura de arquivos disponíveis para o tráfego BitTorrent. Um exemplo é “SampleCaptures/BitTorrent.Transfer1.Cap, “capturado usando o Microsoft Network Monitor. Ele contém alguns pacotes BitTorrent obtidos ao baixar no BitTorrent. Outro exemplo é “SampleCaptures/BitTorrent.PCAP, “capturado usando libpcap. Ele captura a comunicação entre dois clientes de torrent sem DHT ou troca de pares.


P: Como posso exibir apenas tráfego BitTorrent em Wireshark?

R: Para exibir apenas tráfego baseado em BitTorrent no Wireshark, você pode usar o filtro de exibição “BitTorrent.”A aplicação deste filtro mostrará apenas os pacotes relacionados ao tráfego BitTorrent. Observe que este filtro pode estar disponível no Wireshark após uma versão específica (detalhes não fornecidos).


P: É possível capturar apenas tráfego do rastreador BitTorrent usando um filtro específico?

R: Ao capturar o tráfego da rede, não é possível filtrar diretamente os protocolos BitTorrent. No entanto, se você conhece a porta TCP usada pelo rastreador BitTorrent (como 6881), você pode definir um filtro de captura para capturar apenas o tráfego sobre essa porta. Por exemplo, o filtro de captura “TCP Port 6881” capturará apenas o tráfego do rastreador BitTorrent na porta 6881. Além disso, você pode capturar o tráfego do rastreador BitTorrent em uma variedade de portas padrão (e.g., 6881-6889) Usando o filtro “TCP Portrange 6881-6889.”


P: Existem links externos relacionados ao BitTorrent?

R: Sim, aqui estão alguns links externos relacionados ao BitTorrent:


P: Como o protocolo DHT funciona em BitTorrent?

R: O protocolo DHT em BitTorrent utiliza uma tabela de hash distribuída para armazenar e recuperar informações de contato de pares para torrents sem rastrear. Cada nó no DHT tem um identificador globalmente único conhecido como “ID do nó.”Os nós mantêm uma tabela de roteamento que contém informações de contato para outros nós. A tabela de roteamento se torna mais detalhada à medida que os nós se aproximam de seu próprio ID do nó. Essa estrutura permite que nós descubram e se conectem com colegas com eficiência.

Informações adicionais

BitTorrent.Org é o site oficial do BitTorrent. Ele fornece recursos, documentação e atualizações sobre o protocolo BitTorrent e suas implementações. BitTorrent usa o protocolo DHT para permitir torrents sem rastrear, o que aumenta a escalabilidade e a descentralização do processo de compartilhamento de arquivos. O protocolo DHT é implementado sobre UDP e conta com nós para armazenar e recuperar informações de contato de pares.

Nota: Este artigo fornece uma visão geral concisa do BitTorrent, sua extensão DHT e informações relacionadas. Para detalhes mais aprofundados e especificações técnicas, é recomendável visitar o site oficial do BitTorrent e os links externos fornecidos.

BitTorrent usa DHT

Depois de você’Encontrei todos os seus colegas, seu download começa!

BitTorrent

BitTorrent é um protocolo projetado para transferir arquivos. É de natureza ponto a ponto, à medida que os usuários se conectam diretamente para enviar e receber partes do arquivo. No entanto, existe um servidor central (chamado de rastreador) que coordena a ação de todos esses colegas. O rastreador gerencia apenas conexões, não possui nenhum conhecimento do conteúdo dos arquivos que estão sendo distribuídos e, portanto, um grande número de usuários pode ser suportado com largura de banda do rastreador relativamente limitado.

Uma extensão recente para o BitTorrent é o protocolo DHT (“Distributed Sloppy Hash” ou simplesmente chamado de rastreador UDP). Um protocolo de rastreador de pares para pares baseado em UDP. E o uTorrent importa outro protocolo de micro transporte baseado em UDP, chamado UTP.

História

Em abril de 2001, Bram Cohen projetou o protocolo BitTorrent, que ele implementou no verão de 2002. O primeiro programa a usar o protocolo foi o cliente BitTorrent original. Hoje, muitas aplicações estão disponíveis e o protocolo é amplamente utilizado.

Dependências de protocolo

  • TCP: Normalmente, o BitTorrent usa o TCP como seu protocolo de transporte. A conhecida porta TCP para tráfego de BitTorrent é 6881-6889 (e 6969 para a porta do rastreador). A extensão DHT (Peer2Peer Tracker) usa várias portas UDP negociadas pelos pares.

Exemplo de tráfego

Xxx – Adicione o tráfego de exemplo aqui (como texto simples ou screenshot de Wireshark).

Wireshark

O dissector BitTorrent é (totalmente funcional, parcialmente funcional, não existente,… qualquer que seja o estado atual). A extensão DHT foi suportada desde R39653. A extensão UTP foi suportada desde R36716.

Configurações de preferência

  • Remonte as mensagens BitTorrent que abrangem vários segmentos TCP
  • Decodificar o peer_id das mensagens de aperto de mão

Exemplo de captura arquivos

SampleCaptures/BitTorrent.Transfer1.Cap (Microsoft Network Monitor) Aqui está uma captura com alguns pacotes BitTorrent; Ele contém alguns pacotes pequenos que recebi enquanto baixava algo no BitTorrent.

SampleCaptures/BitTorrent.PCAP (LIBPCAP) Arquivo.

Exibir filtro

Uma lista completa de campos de filtro de exibição BitTorrent pode ser encontrada na referência do filtro de exibição

Mostre apenas o tráfego baseado em BitTorrent:

 BitTorrent

Nota: Implementado no Wireshark Post 0.10.12!

Capture filtro

Você não pode filtrar diretamente os protocolos BitTorrent enquanto captura. No entanto, se você conhece a porta TCP usada (veja acima), você pode filtrar nessa.

Capture apenas o tráfego do rastreador BitTorrent sobre uma das portas padrão (e.g. 6881):

 Porta TCP 6881

Capture o tráfego do rastreador BitTorrent na faixa de portas padrão (e.g. 6881-6889):

 TCP Portange 6881-6889

Ao usar libpcap 0.9.1 ou mais tarde ou Winpcap 3.1 ou mais tarde; Essa expressão não funcionará com versões mais antigas do libpcap ou winpcap; portanto, no Windows, atualize para o winpcap 3.1 ou posterior e, na un*x, atualize para libpcap 0.9.x se possível e, se não for possível, e você terá uma versão do libpcap antes de 0.8.1, use

 (TCP [0: 2]> = 6881 e TCP [0: 2] = 6881 e TCP [2: 2]

(um bug no otimizador LibPCAP no libpcap 0.8.x significa que isso não funcionará com libpcap 0.8.x, embora você possa usar o tcpdump com a bandeira "-o").

links externos

  • http: // www.BitTorrent.com/ a página oficial do BitTorrent
  • Página da Wikipedia BitTorrent
  • Como o BitTorrent funciona sobre P2P em geral, configurações de BitTorrent e Firewall
  • Protocolo DHT (BEP 5), a extensão BitTorrent baseada em UDP para rastreadores distribuídos (o número da porta UDP é negociado). Além disso: link para rascunho do protocolo DHT (link morto), cópia do arquivo da web (2007-12-21) do Protocolo DHT de Rascunho.
  • Assinatura do protocolo hippie Descrição As assinaturas de protocolo TCP e UDP que podem ser usadas para identificar heuristicamente o link de arquivo da web protocolo bittorrent
  • Mais sobre BitTorrent

BitTorrent .org

O BitTorrent usa uma "tabela de hash desleixada distribuída" (DHT) para armazenar informações de contato de pares para torrents "Rackerless". Na verdade, cada colega se torna um rastreador. O protocolo é baseado em Kademila [1] e é implementado sobre UDP.

Observe a terminologia usada neste documento para evitar confusão. Um "par" é um cliente/servidor ouvindo em uma porta TCP que implementa o protocolo BitTorrent. Um "nó" é um cliente/servidor ouvindo em uma porta UDP implementando o protocolo de tabela de hash distribuída. O DHT é composto de nós e armazena a localização dos colegas. Os clientes do BitTorrent incluem um nó DHT, que é usado para entrar em contato com outros nós no DHT para obter a localização dos colegas para baixar usando o protocolo BitTorrent.

Visão geral

Cada nó tem um identificador globalmente exclusivo conhecido como "ID do nó."Os IDs dos nó são escolhidos aleatoriamente no mesmo espaço de 160 bits que BitTorrent Infohashes [2]. Uma "métrica de distância" é usada para comparar dois IDs de nós ou um ID do nó e um infoHash para "proximidade."Os nós devem manter uma tabela de roteamento que contém as informações de contato para um pequeno número de outros nós. A tabela de roteamento se torna mais detalhada à medida que os IDs se aproximam do próprio ID do nó. Os nós sabem sobre muitos outros nós no DHT que têm IDs que são "próximos" do seu, mas têm apenas um punhado de contatos com IDs que estão muito longe de seus.

Na Kademlia, a métrica de distância é XOR e o resultado é interpretado como um número inteiro não assinado. distância (a, b) = | a xor b | Valores menores estão mais próximos.

Quando um nó quer encontrar colegas para uma torrente, ele usa a métrica de distância para comparar o InfoHash da torrent com os IDs dos nós em sua própria tabela de roteamento. Em seguida, entra em contato com os nós que conhece com os IDs mais próximos do InfoHash e pede a eles as informações de contato de colegas que atualmente baixam o torrent. Se um nó contatado souber sobre colegas para o torrent, as informações de contato de pares serão retornadas com a resposta. Caso contrário, o nó contatado deve responder com as informações de contato dos nós em sua tabela de roteamento mais próximos da informação do torrent. O nó original consulta iterativamente os nós que estão mais próximos do InfoHash de destino até que não consiga encontrar nenhum nós mais próximo. Depois que a pesquisa se esgota, o cliente insere as informações de contato de pares nos nós que respondem com os IDs mais próximos da informação do torrent.

O valor de retorno para uma consulta para colegas inclui um valor opaco conhecido como "token."Para que um nó anuncie que seu colega controlador está baixando uma torrent, ele deve apresentar o token recebido do mesmo nó consultado em uma consulta recente para colegas. Quando um nó tenta "anunciar" uma torrente, o nó consultado verifica o token contra o endereço IP do nó de consulta. Isso é para impedir que hosts maliciosos se inscrevam em outros anfitriões para torrents. Como o token é meramente devolvido pelo nó de consulta ao mesmo nó da qual recebeu o token, a implementação não é definida. Os tokens devem ser aceitos por uma quantidade razoável de tempo depois de terem sido distribuídos. A implementação do BitTorrent usa o hash sha1 do endereço IP concatenado em um segredo que muda a cada cinco minutos e tokens até dez minutos de idade são aceitos.

Tabela de roteamento

Cada nó mantém uma tabela de roteamento de bons nós conhecidos. Os nós na tabela de roteamento são usados ​​como pontos de partida para consultas no DHT. Os nós da tabela de roteamento são retornados em resposta a consultas de outros nós.

Nem todos os nós sobre os quais aprendemos são iguais. Alguns são "bons" e outros não são. Muitos nós usando o DHT são capazes de enviar consultas e receber respostas, mas não conseguem responder a consultas de outros nós. É importante que a tabela de roteamento de cada nó deve conter apenas bons nós conhecidos. Um bom nó é um nó respondeu a uma de nossas consultas nos últimos 15 minutos. Um nó também é bom se já respondeu a uma de nossas consultas e nos enviou uma consulta nos últimos 15 minutos. Após 15 minutos de inatividade, um nó se torna questionável. Os nós ficam ruins quando não respondem a várias consultas consecutivas. Nós que sabemos que são bons recebem prioridade sobre nós com status desconhecido.

A tabela de roteamento cobre todo o espaço de identificação do nó de 0 a 2 160 . A tabela de roteamento é subdividida em "baldes" que cobrem uma parte do espaço. Uma tabela vazia tem um balde com um espaço de identificação de min = 0, max = 2 160 . Quando um nó com id "n" é inserido na mesa, ele é colocado dentro do balde que tem min <= N < máx. Uma mesa vazia tem apenas um balde, então qualquer nó deve caber nele. Cada balde só pode conter os nós K, atualmente oito, antes de se tornar "cheio."Quando um balde está cheio de bons nós conhecidos, não há mais nós, a menos que nosso próprio ID do nó se enquadre dentro do alcance do balde. Nesse caso, o balde é substituído por dois novos baldes, cada um com metade do alcance do antigo balde e os nós do antigo balde são distribuídos entre os dois novos. Para uma nova mesa com apenas um balde, o balde completo é sempre dividido em dois novos baldes cobrindo os intervalos 0..2 159 e 2 159 ..2 160 .

Quando o balde está cheio de bons nós, o novo nó é simplesmente descartado. Se conhecidos algum nós no balde terem se tornado ruins, então um será substituído pelo novo nó. Se houver algum nós questionáveis ​​no balde não foram vistos nos últimos 15 minutos, o nó menos recentemente visto é pingado. Se o nó pingado responder, então o nó interrogado menos recentemente visto é pingado até que alguém não responda ou todos os nós do balde são conhecidos por serem bons. Se um nó no balde falhar em responder a um ping, é sugerido tentar mais uma vez antes de descartar o nó e substituí -lo por um novo bom nó. Dessa forma, a mesa se enche de nós estáveis ​​de longa execução.

Cada balde deve manter uma propriedade "alterada pela última. Quando um nó em um balde é pingado e responde, ou um nó é adicionado a um balde, ou um nó em um balde é substituído por outro nó, a última propriedade alterada do balde deve ser atualizada. Baldes que não foram alterados em 15 minutos devem ser "atualizados."Isso é feito escolhendo um ID aleatório no intervalo do balde e realizando uma pesquisa find_nodes. Nós que são capazes de receber consultas de outros nós geralmente não precisam atualizar os baldes frequentemente. Nós que não são capazes de receber consultas de outros nós geralmente precisarão atualizar todos os baldes periodicamente para garantir que haja bons nós em sua mesa quando o DHT for necessário.

Ao inserir o primeiro nó em sua tabela de roteamento e, ao iniciar a partir de então, o nó deve tentar encontrar os nós mais próximos no DHT para si mesmo. Faz isso emitindo mensagens find_node para nós mais próximos e mais próximos até que não possa encontrar nenhum. A tabela de roteamento deve ser salva entre as invocações do software cliente.

Extensão do protocolo BitTorrent

O protocolo BitTorrent foi estendido para trocar números de porta UDP entre pares que são introduzidos por um rastreador. Dessa forma, os clientes podem obter suas tabelas de roteamento automaticamente através do download de torrents regulares. Clientes recém -instalados que tentam baixar uma torrent sem rastrear na primeira tentativa não terão nenhum nós em sua tabela de roteamento e precisarão dos contatos incluídos no arquivo torrent.

Colegas que apoiam o DHT definiram o último bit das bandeiras reservadas de 8 bytes trocadas no handshake de protocolo BitTorrent. Pares recebendo um aperto de mão indicando que o par suporta o DHT deve enviar uma mensagem de porta. Começa com o byte 0x09 e possui uma carga útil de dois bytes contendo a porta UDP do nó DHT em ordem de byte de rede. Os colegas que recebem esta mensagem devem tentar ping no nó na porta recebida e no endereço IP do par de remoto. Se uma resposta ao ping for recebida, o nó deve tentar inserir as novas informações de contato em sua tabela de roteamento de acordo com as regras usuais.

Extensões de arquivo torrent

Um dicionário de torrent sem rastreador não possui uma chave de "anunciar". Em vez disso, uma torrent sem rastreador tem uma chave "nós". Essa chave deve ser definida para os nós mais próximos na tabela de roteamento do cliente gerador de torrent. Como alternativa, a chave pode ser definida para um bom nó conhecido, como um operado pela pessoa que gera o torrent. Por favor, não adicione automaticamente "roteador.BitTorrent.com "para arquivos torrent ou adicionar automaticamente este nó às tabelas de roteamento de clientes.

nós = [["",], ["",], . ] nós = [["127.0.0.1 ", 6881], [" seu.roteador.Nó ", 4804], [" 2001: DB8: 100: 0: D5C8: DB3F: 995E: C0F7 ", 1941]]

Protocolo KRPC

O protocolo KRPC é um mecanismo RPC simples que consiste em dicionários de bindado enviados por UDP. Um único pacote de consulta é enviado e um único pacote é enviado em resposta. Não há tentativa. Existem três tipos de mensagens: consulta, resposta e erro. Para o protocolo DHT, existem quatro consultas: ping, find_node, get_peers e anuncie_peer.

Uma mensagem KRPC é um único dicionário com três chaves comuns a cada mensagem e chaves adicionais, dependendo do tipo de mensagem. Cada mensagem tem uma chave "T" com um valor de string representando um ID de transação. Este ID da transação é gerado pelo nó de consulta e é ecoado na resposta, portanto as respostas podem estar correlacionadas com várias consultas com o mesmo nó. O ID da transação deve ser codificado como uma pequena série de números binários, normalmente 2 caracteres são suficientes, pois cobrem 2^16 consultas pendentes. Cada mensagem também tem uma chave "y" com um único valor de caractere descrevendo o tipo de mensagem. O valor da tecla "Y" é uma de "q" para consulta, "r" para resposta, ou "e" para erro. Uma chave "V" deve ser incluída em todas as mensagens com uma string de versão do cliente. A string deve ser um identificador de cliente de dois caracteres registrado no BEP 20 [3], seguido por um identificador de versão de dois caracteres. Nem todas as implementações incluem uma chave "V" para que os clientes não devem assumir sua presença.

Codificação de contato

As informações de contato para colegas são codificadas como uma corda de 6 bytes. Também conhecido como "compacto ip-address/port info", o endereço IP de 4 bytes está em ordem de bytes de rede com a porta de 2 bytes em ordem de bytes de rede concatenada no final.

As informações de contato para nós são codificadas como uma corda de 26 bytes. Também conhecido como "Info Nó Compacto" O ID do Nó de 20 bytes em Pedido de Byte de Rede tem a compacta IP-Address/Port Info Concatenated to the End.

Perguntas

Consultas, ou dicionários de mensagem KRPC com um valor "y" de "q", contêm duas chaves adicionais; "Q" e "A". Chave "q" tem um valor de string contendo o nome do método da consulta. Key "A" tem um valor de dicionário contendo argumentos nomeados para a consulta.

Respostas

Respostas, ou dicionários de mensagem KRPC com um valor "y" de "r", contêm uma chave adicional "r". O valor de "R" é um dicionário que contém valores de retorno nomeados. As mensagens de resposta são enviadas após a conclusão bem -sucedida de uma consulta.

Erros

Erros, ou dicionários de mensagem KRPC com um valor "y" de "e", contêm uma chave adicional "e". O valor de "E" é uma lista. O primeiro elemento é um número inteiro que representa o código de erro. O segundo elemento é uma string que contém a mensagem de erro. Erros são enviados quando uma consulta não pode ser realizada. A tabela a seguir descreve os possíveis códigos de erro:

Código Descrição
201 Erro genérico
202 erro de servidor
203 Erro de protocolo, como um pacote malformado, argumentos inválidos ou token ruim
204 Método desconhecido

Pacotes de erro de exemplo:

Erro genérico = BenCoded = D1: ELI201E23: Um erro genérico ocurrede1: T2: aa1: y1: ee

Consultas DHT

Todas as consultas têm uma tecla "id" e valor contendo o ID do nó do nó de consulta. Todas as respostas têm uma tecla "id" e valor contendo o ID do nó do nó que responde.

ping

A consulta mais básica é um ping. "q" = "ping" Uma consulta de ping tem um único argumento, "id", o valor é uma string de 20 bytes que contém o ID do nó dos remetentes no pedido de byte de rede. A resposta apropriada a um ping tem uma única chave "id" contendo o nó ID do nó que responde.

Argumentos: "> Resposta:">

Ping Query => BenCoded = D1: AD2: ID20: ABCDEFGHIJ0123456789E1: Q4: Ping1: T2: AA1: Y1: QE

Resposta => BenCoded = D1: RD2: ID20: mnopqrstuvwxyz123456e1: T2: AA1: Y1: RE

FIND_NODE

O nó de encontro é usado para encontrar as informações de contato para um nó, dado seu id. "q" == "find_node" Uma consulta find_node tem dois argumentos, "id" contendo o ID do nó do nó de consulta, e "alvo" contendo o id do nó procurado pelo consultor. Quando um nó recebe uma consulta find_node, ele deve responder com uma chave "nós" e o valor de uma string que contém as informações do nó compacto para o nó de destino ou o k (8) mais próximos nós em sua própria tabela de roteamento.

Argumentos: "," Target ":" "> Resposta:", "nós": "">>

find_node Query => BenCoded = D1: AD2: ID20: ABCDEFGHIJ01234567896: Target20: Mnopqrstuvwxyz123456e1: Q9: find_node1: T2: aa1: y1: qe

Resposta => BenCoded = D1: RD2: ID20: 0123456789ABCDEFGHIJ5: NÓS9: DEF456. E1: T2: AA1: Y1: RE

get_peers

Obtenha colegas associados a um torrent infoHash. "q" = "get_peers" a get_peers Query tem dois argumentos, "id" contendo o ID do nó do nó de consulta e "info_hash" contendo o InfoHash do torrent. Se o nó consultado tiver colegas para o InfoHash, eles serão devolvidos em um "valores" importantes como uma lista de strings. Cada string contendo informações de pares de formato "compacto" para um único par. Se o nó consultado não tiver colegas para o InfoHash, um "nós" chave "é retornado contendo os K nós nos nós consultados de roteamento da tabela mais próxima do InfoHash fornecido na consulta. Em ambos os casos, uma chave "token" também está incluída no valor de retorno. O valor do token é um argumento necessário para uma consulta futura para anunciar_peer. O valor do token deve ser uma corda binária curta.

Argumentos: "," info_hash ":" "> resposta:", "token": "", "valores": ["", ""]> ou: "," token ":" "," nós ":" ">>>

get_peers Query => BenCoded = D1: AD2: ID20: abcdefghij01234567899: info_hash20: mnopqrstuvwxyz123456e1: q9: get_peers1: t2: aa1: y1: qe

Resposta com pares => BenCoded = D1: RD2: ID20: ABCDEFGHIJ01234567895: Token8: AoEusnth6: valoresl6: Axje.u6: idhtnmee1: t2: aa1: y1: re

Resposta com nós mais próximos => BenCoded = D1: RD2: ID20: ABCDEFGHIJ01234567895: NÓS9: DEF456. 5: token8: aoeusnthe1: t2: aa1: y1: re

anuncie_peer

Anuncie que o colega, controlando o nó de consulta, está baixando uma torrente em uma porta. Announce_peer tem quatro argumentos: "ID" contendo o ID do nó do nó de consulta, "info_hash", contendo o InfoHash do torrent, "porta" contendo a porta como um número inteiro, e o "token" recebido em resposta a uma consulta Get_peers anterior anterior. O nó consultado deve verificar se o token foi enviado anteriormente para o mesmo endereço IP que o nó de consulta. Em seguida, o nó consultado deve armazenar o endereço IP do nó de consulta e o número da porta fornecida sob o InfoHash em sua loja de informações de contato de pares.

Há um argumento opcional chamado implícito_port Qual valor é 0 ou 1. Se estiver presente e diferente de zero, o porta O argumento deve ser ignorado e a porta de origem do pacote UDP deve ser usada como porta do par em vez. Isso é útil para colegas por trás de um NAT que pode não conhecer sua porta externa e apoiar o UTP, eles aceitam conexões de entrada na mesma porta que a porta DHT.

Argumentos: "," Imply_port ":," info_hash ":" "," porta ":," token ":" "> resposta:">

AnNounce_peers Query => BenCoded = D1: AD2: ID20: ABCDEFGHIJ012345678912: Implied_porti1e9: info_hash20: mnopqrstwxyz1234564: porti681e5: token8: aoEusn134564

Resposta => BenCoded = D1: RD2: ID20: mnopqrstuvwxyz123456e1: T2: AA1: Y1: RE

Referências

[1] Peter Maymounkov, David Mazieres, "Kademlia: um sistema de informações ponto a ponto baseado na métrica XOR", IPTPS 2002. http: // www.cs.arroz.EDU/Conferências/IPTPS02/109.pdf
[2] Use SHA1 e muita entropia para garantir um ID único.
[3] BEP_0020. Convenções de identificação de pares. (http: // www.BitTorrent.org/beps/bep_0020.html)

direito autoral

Este documento foi colocado em domínio público.

WebTorrent/BitTorrent-DHT

Este compromisso não pertence a nenhum ramo neste repositório e pode pertencer a um garfo fora do repositório.

Switch Branches/Tags

Tags de ramificações

Não foi possível carregar ramificações

Nada para mostrar

Não foi possível carregar tags

Nada para mostrar

Nome já em uso

Uma tag já existe com o nome da filial fornecida. Muitos comandos Git aceitam nomes de tag e ramificação; portanto, criar este ramo pode causar comportamento inesperado. Tem certeza que deseja criar este ramo?

Cancelar Criar

  • Local
  • Codespaces

Https github cli

Use Git ou Checkout com SVN usando o URL da Web.

Trabalhe rápido com nossa cli oficial. Saiba mais sobre a CLI.

Autenticação necessária

Faça login para usar os espaços de codificina.

Lançando o GitHub Desktop

Se nada acontecer, faça o download do GitHub Desktop e tente novamente.

Lançando o GitHub Desktop

Se nada acontecer, faça o download do GitHub Desktop e tente novamente.

Lançando Xcode

Se nada acontecer, faça o download do Xcode e tente novamente.

Lançando o código do Visual Studio

Seu espaço de código será aberto uma vez pronto.

Houve um problema para preparar seu espaço de código, por favor tente novamente.

Última confirmação

3b4ed64 8 de maio de 2023

… V1.0.9

Estatísticas Git

arquivos

Falha ao carregar informações mais recentes de compromisso.

Última mensagem de confirmação

Comprometer o tempo

Leia-me.MD

Implementação simples, robusta, BitTorrent DHT

Nó.Implementação do JS do protocolo BitTorrent DHT. O BitTorrent DHT é a principal camada de descoberta de pares do BitTorrent, que permite torrents sem rastrear. DHTS são incríveis!

Este módulo é usado pelo WebTorrent.

  • Implementação completa do protocolo DHT em JavaScript
  • segue a especificação
  • suporta BEP44 para armazenar dados arbitrários no DHT
  • robusto e bem testado
    • Suíte de teste abrangente e totalmente offline
    • Usado por WebTorrent, Peerflix e Playback

    NPM Instale BitTorrent-DHT 

    NPM Install Magnet-Uri 

    importar Dht de 'bittorrent-dht' importar magnético de 'ímã-uri' const Uri = 'magnético:?XT = urn: BTIH: E3811B9539CACFF680E418124272177C47777157 ' const analisado = magnético(Uri) console.registro(analisado.infoHash) // 'e3811b9539cacff680e418124272177c47777157' const dht = novo Dht() dht.ouvir(20000, função ()  console.registro('agora ouvindo') >) dht.sobre('par', função (par, infoHash, de)  console.registro('encontrado em potencial' + par.hospedar + ':' + par.porta + ' através ' + de.endereço + ':' + de.porta) >) // Encontre colegas para o hash de informações de torrent fornecido dht.olho para cima(analisado.infoHash)

    dht = novo dht ([opts])

    Crie uma nova instância DHT.

    Se o OPTS for especificado, as opções padrão (mostradas abaixo) serão substituídas.

     nodeid: '', // ID do nó DHT de 160 bits (Buffer ou String Hex, padrão: gerado aleatoriamente) Bootstrap: [[], // Bootstrap Servers (padrão: roteador.BitTorrent.com: 6881, roteador.uTorrent.com: 6881, dht.transmissionBt.com: 6881) hospedar: falso, // host de pares locais, se especificado, anuncia ser adicionado à tabela local (string, desativada por padrão) simultaneidade: 16, // Opção K-RPC para especificar solicitações UDP máximas permitidas (número, 16 por padrão) cerquilha: Função, // Função de hash personalizada a ser usada (função, sha1 por padrão), Krpc: Krpc(), // instância opcional k-rpc TimeBucketOutdated: 900000, // Verifique os baldes a cada 15min Maxage: Infinidade // Configuração opcional para colegas anunciados para passar o tempo >

    Para usar dht_store, defina optas.Verifique a uma implementação ED25519 Supercop/Ref10. Optos.Verifique (assinatura, valor, PublicKey) deve devolver um booleano se os buffers de assinatura e valor foram gerados pelo público .

    Por exemplo, para dht_store, você pode fazer:

    importar ed de 'ED25519-SUPERCOP' const dht = novo Dht( verificar: ed.verificar >)

    Encontre colegas para o hash de informações dadas.

    Isso faz uma pesquisa recursiva no DHT. Os colegas potenciais descobertos são emitidos como eventos de pares. Veja o evento de colegas abaixo para obter mais informações.

    InfoHash pode ser uma corda ou buffer. O retorno de chamada é chamado quando a pesquisa recursiva terminou e é chamada com dois parâmetros. O primeiro é um erro ou nulo. O segundo é o número de nós encontrados que tinham colegas. Você geralmente não precisa usar essas informações e pode simplesmente ouvir eventos de colegas.

    Retorna uma função abort () que nos permitiria abortar a consulta.

    dht.Ouça ([Port], [endereço], [Listenamento])

    Faça o DHT ouvir na porta dada . Se a porta for indefinida, uma porta disponível será automaticamente colhida.

    Se o endereço for indefinido, o DHT tentará ouvir em todos os endereços.

    Se a lista de lançamento estiver definida, ele está anexado ao evento de escuta.

    Retorna um objeto que contém as informações do endereço para a soquete de escuta do DHT. Este objeto contém propriedades de endereço, família e porta.

    dht.Anunciar (InfoHash, [Port], [retorno de chamada])

    Anuncie que o colega, controlando o nó de consulta, está baixando uma torrente em uma porta.

    Se você omitir a porta, a opção de porta implícita será definida e outros pares usarão a porta DHT pública como sua porta anunciada.

    Se dht.anunciar é chamado e não há tabela de roteamento em cache, depois um dht.A pesquisa será realizada primeiro para descobrir nós relevantes e obter "tokens" válidos de cada um deles. Isso vai demorar mais.

    Um "token" é um valor opaco que deve ser apresentado para um nó anunciar que seu colega de controle está baixando um torrent. Deve apresentar o token recebido do mesmo nó consultado em uma consulta recente para os colegas. Isso é para impedir que hosts maliciosos se inscrevam em outros anfitriões para torrents. Todo o gerenciamento de token é tratado internamente por este módulo.

    O retorno de chamada será chamado quando a operação de anunciar for concluída e for chamada com um único parâmetro que é um erro ou nulo.

    Retorna o estado atual do DHT, incluindo nós DHT e valores BEP44.

    < "nós": [], "Valores": <>>

    Os nós DHT, em particular, são úteis para persistir no DHT em disco entre os reinicialização de um cliente BitTorrent (conforme recomendado pela especificação). Cada nó na matriz é um objeto com propriedades de host (string) e porta (número).

    Para restaurar os nós DHT ao instantar um novo objeto DHT, basta dar um loop sobre os nós na matriz e adicione -os com o método AddNode.

    const DHT1 = novo Dht() // Algum tempo passa . // Destrua o DHT const nós = DHT1.Tojson().nós DHT1.destruir() // Algum tempo passa . // inicialize um novo DHT com a mesma tabela de roteamento que a primeira const dht2 = novo Dht() nós.para cada(função (nó)  dht2.addNode(nó) >)

    Adicione manualmente um nó à tabela de roteamento DHT. Se houver espaço na tabela de roteamento (ou um nó que não responde pode ser despejado para abrir espaço), o nó será adicionado. Caso contrário, o nó não será adicionado. Isso é útil para chamar quando um fio de pares envia uma mensagem de porta para compartilhar sua porta DHT.

    Um nó deve ficar assim:

     hospedar: Nodehost, porta: NodEport >

    Destrua o DHT. Fecha o soquete e limpa os grandes recursos da estrutura de dados.

    Escreva uma carga útil arbitrária para o DHT. (BEP 44).

    Para todas as solicitações, você deve especificar:

    • Opts.V - Uma carga útil de buffer para escrever, menos de 1000 bytes

    Se você especificar apenas optos.V, o conteúdo é considerado imutável e o hash será apenas o hash do conteúdo.

    Aqui está um exemplo simples de criar algum conteúdo imutável no DHT:

    importar Dht de 'bittorrent-dht' const dht = novo Dht() const valor = Amortecedor.aloc(200).preencher('abc') dht.colocar( v: valor >, função (errar, cerquilha)  console.erro('Error =', errar) console.registro('Hash =', cerquilha) >)

    Para conteúdo mutável, o hash será o hash da chave pública, opta.k . Essas opções estão disponíveis:

    • Opts.K - ED25519 Buffer de chave pública (32 bytes) (obrigatório)
    • Optos.Sign (BUF) - Função para gerar um buffer de assinatura ED25519 (64 bytes) correspondente aos OPTs.K chave pública (exigida)
    • Optos.SEQ - Sequência opcional (número inteiro), deve aumentar monotonicamente (necessário)
    • Opts.CAS-Sequência anterior opcional para comparar e trocar
    • Opts.sal - tampão de sal opcional para incluir (

    Observe que o BitTorrent Bep44 usa o ED25519. Você pode usar o pacote ED25519-SUPERCOP para gerar as assinaturas apropriadas, BitTorrent-Dht-Store-Kyypair, BitTorrent-Dht-Sodium ou para uma versão mais conveniente.

    Para fazer uma atualização mutável, você precisará criar uma chave elíptica e empacotar valores com precisão de acordo com a especificação, assim:

    importar ed de 'BitTorrent-dht-sodium' const Keypair = ed.keygen() const valor = Amortecedor.aloc(200).preencher('qualquer que seja') // a carga útil que você deseja enviar const Opts =  k: Keypair.pk, Seq: 0, v: valor, sinal: função (BUF)  retornar ed.sinal(BUF, Keypair.sk) > > importar Dht de 'bittorrent-dht' const dht = novo Dht() dht.colocar(Opts, função (errar, cerquilha)  console.erro('Error =', errar) console.registro('Hash =', cerquilha) >)

    Em formas mutáveis ​​ou imutáveis, o retorno de chamada (erro, hash, n) dispara com um erro se nenhum nós foi capaz de armazenar o valor . n está definido a quantidade de colegas que aceitaram o put e o hash, o local onde o conteúdo mutável ou imutável pode ser recuperado (com DHT.obtenha (hash)).

    Observe que você deve ligar .Coloque () a cada hora para o conteúdo que você deseja manter vivo, pois os nós podem descartar os nós de dados com mais de 2 horas.

    Se você receber um par de chaves/valor e deseja re-adquirir ao DHT para mantê-lo vivo, você pode simplesmente colocá-lo novamente.

    importar ed de 'BitTorrent-dht-sodium' const dht = novo Dht( verificar: ed.verificar >) // você deve especificar o parâmetro "verifique" se quiser obter conteúdo mutável; caso contrário, o nulo será devolvido dht.pegar(chave, função (errar, res)  dht.colocar(res, função ()  // re-adquiriu o par de chaves/valor >) >)

    dht.Obtenha (hash, opts, retorno de chamada)

    Leia um registro de dados (criado com .put ()) do DHT. (BEP 44)

    Dado hash, uma string ou buffer hexadecida, conteúdo de dados de pesquisa do DHT, enviando o resultado em retorno de chamada (err, res) .

    Essas opções estão disponíveis:

    • Optos.Verifique - Substituir a função de verificação ED25519 padrão fornecida durante a instanciação DHT.
    • Optos.sal - tampão de sal opcional (se houver) que foi usado para calcular o hash. Deve ser especificado se incluído no hash.
    • Optos.Cache - Use o valor de resposta localmente em cache, quando disponível em vez de executar uma pesquisa de rede (padrão para true).

    Os objetos res são semelhantes aos objetos de opções escritos ao DHT com .colocar() :

    • res.V - o valor colocado em
    • res.ID - o nó que retornou o conteúdo
    • res.K - A chave pública (presente apenas para dados mutáveis)
    • res.SIG - A assinatura (presente apenas para dados mutáveis)
    • res.SEQ - A sequência (opcional, presente apenas para dados mutáveis)

    Emitido quando o DHT é totalmente inicializado (i.e. A tabela de roteamento é suficientemente povoada através dos nós de bootstrap). Observe que não há problema em fazer pesquisas antes do evento 'pronto'.

    Nota: Se você inicializar o DHT com o < bootstrap: false >Opção, então o evento 'Ready' disparará no próximo tick, mesmo que não haja nenhum nós na tabela de roteamento. Supõe -se que você preencha manualmente a tabela de roteamento com DHT.Adicione se você passar nesta opção.

    Emitido quando o DHT está ouvindo.

    dht.on ('par', função (par, infohash, de) < . >)

    Emitido quando um par em potencial é encontrado. par é da forma . infohash é o hash de torrent hash of the swarm que o par pertence. Emitido em resposta a uma pesquisa (infoHash).

    dht.on ('Erro', função (err) < . >)

    Emitido quando o DHT tem um erro fatal.

    dht.on ('nó', função (nó) < . >)

    Emitido quando o DHT encontra um novo nó.

    dht.ON ('Anunciar', função (par, infoHash) < . >)

    Emitido quando um colega se anuncia para ser armazenado no DHT.

    dht.on ('Aviso', função (err) < . >)

    Emitido quando o DHT recebe uma mensagem inesperada de outro nó DHT. Isso é puramente informativo.

    • Protocolo BitTorrent DHT
    • Kademlia: um sistema de informações ponto a ponto baseado na métrica XOR

    MTE explica: Como funciona o BitTorrent DHT Peer Discovery

    A descoberta de pares é uma parte essencial do protocolo BitTorrent. Isto&rsquo;s como seus downloads acontecem tão rapidamente: você se conecta a várias pessoas, e cada um deles carrega um pequeno pedaço do arquivo para você. Esse fenômeno criou uma maneira muito popular de baixar e compartilhar informações na internet, legítima e ilegítima. Independentemente dos efeitos que teve na propriedade intelectual, eu&rsquo;estou aqui para descrever uma coisa: como todo o processo de descoberta de pares dht bittorrent realmente funciona. Você pode saber um pouco (ou muito) sobre esse mecanismo, mas com certeza você&rsquo;estou curioso para saber o que o termo DHT significa e como os pares listados nele o encontraram em primeiro lugar.

    O que significa DHT?

    DHT é curto para &ldquo;Tabela de hash distribuída,&rdquo; e representa um meio pelo qual você encontra colegas, também conhecido como &ldquo;Bootstrapping.&rdquo; EU&rsquo;Explicarei isso daqui a pouco. Lembre -se do fato de que você pode encontrar colegas através do DHT.

    BitTorrent DHT Localização

    Enquanto muitas pessoas dizem isso&rsquo;é descentralizado, isso&rsquo;é realmente muito difícil de fazer isso, dada a natureza unicast da internet. Quando você se conecta à web, você não&rsquo;t Anuncia sua presença aos bilhões de computadores já conectados. Isso apenas desperdiçaria enormes quantidades de largura de banda. Em vez disso, seu provedor de serviços de Internet local&rsquo;S roteador, assim como os destinos aos quais você se conecta, são os únicos cientes de que você&rsquo;eu mesmo online. Que&rsquo;s o que &ldquo;unicast&rdquo; significa, em leigo&rsquo;s Termos. Multicast é o que acontece quando seu computador entra em uma rede local. Sua presença é divulgada a todos os outros computador na mesma sub -rede, e eles&rsquo;agora estou ciente de sua presença. Já que isso não faz&rsquo;Acontece na Internet externa, lá&rsquo;realmente não há como realmente compor uma estrutura completamente descentralizada, dadas as limitações do próprio protocolo BitTorrent.

    Como resultado, tende a haver dois DHTs principais aos quais você se conecta quando você começa a baixar um arquivo torrent: roteador.BitTorrent.com e roteador.uTorrent.com. No caso de você&rsquo;estou curioso, você se conecta a eles na porta 6881. Isto&rsquo;não é absolutamente necessário para memorizar esta informação. Às vezes, os dados dos pares são incorporados no arquivo torrent para facilitar o processo de encontrar colegas.

    Bootstrapping

    bitdht-descoberta

    Para começar a reunir colegas, é preciso primeiro inicializar na rede de torrent. Bootstrapping é apenas uma maneira chique de descrever o processo de conexão com o DHT e encontrar colegas. Uma vez conectado, o servidor DHT enviará um punhado de endereços IP de pares que você&rsquo;LL também conectar a. Eles&rsquo;Eu darei a você os endereços dos colegas conectados a eles, e assim por diante, e assim por diante, até que sua lista de colegas mostre todos os colegas baixando (ou semeando) o arquivo que você&rsquo;estou tentando conseguir. Isto&rsquo;é como seguir uma árvore das raízes para os galhos.

    Teoricamente falando, você realmente precisa de um único endereço para obter todos os outros colegas, pois ele compartilhará o restante dos endereços com você. Isso salva rastreadores e o DHT uma tonelada de largura de banda que, de outra forma, seria desperdiçada ao enviar listas de colegas para todos os novos pares conectados e notificar cada pessoa quando um deles se desconecta. O incômodo é minimizado, fazendo com que os colegas retransmitam informações.

    Depois de você&rsquo;Encontrei todos os seus colegas, seu download começa!

    Se os DHTs estão lá fora, por que a maioria das pessoas ainda usa rastreadores?

    O DHT pode ser divertido, mas a maioria das pessoas ainda usa rastreadores para baixar seus dados. Isso é por causa da natureza inerente do DHT. Deixar&rsquo;s Diga que tenho um site em que carrego um monte de minhas criações de código aberto como torrents. Para controlar completamente o que acontece com esses torrents e proteger a privacidade dos indivíduos que os baixam, isso&rsquo;é mais lucrativo para eu hospedar meu próprio rastreador. Sites que pós -ilícito de download de material usam rastreadores como meio de preferência para manter um aspecto subterrâneo e controlar o que é publicado neles e o que é removido.

    Dito isto, nem todos os downloads de torrent são ilegais. Lá&rsquo;É um repositório enorme de projetos de código aberto e obras de domínio público de indivíduos que apenas querem compartilhar o que têm sem desperdiçar a largura de banda de seus hosts na web.

    Confuso?

    Se você&rsquo;ainda estou intrigado com as informações compartilhadas aqui, deixe um comentário abaixo e podemos discutir!

    Miguel Leiva-Gomez

    Miguel tem sido um especialista em crescimento e tecnologia dos negócios há mais de uma década e escreveu software por mais tempo. De seu pequeno castelo na Romênia, ele apresenta perspectivas frias e analíticas a coisas que afetam o mundo da tecnologia.

    Assine a nossa newsletter!

    Nossos últimos tutoriais entregues diretamente à sua caixa de entrada