BitTorrent Sobre I2P

Existem vários clientes BitTorrent e Rastreadores no I2P. Como o endereçamento I2P usa um destino em vez de IP e porta, as alterações necessárias no rastreador e no software cliente para operar no I2P são menores. Essas alterações são especificadas abaixo. Observe cuidadosamente as diretrizes para compatibilidade com clientes anteriores e rastreadores I2P.

Esta página especifica detalhes do protocolo comum a todos os clientes e rastreadores. Clientes e rastreadores específicos podem implementar outros recursos ou protocolos exclusivos.

Portas de software de cliente e rastreador adicionais são bem-vindos para i2p.

anúncios

Os clientes geralmente incluem uma porta de parâmetro falso = 6881 no anúncio, por compatibilidade com rastreadores anteriores. Os rastreadores podem ignorar o parâmetro da porta (porta) e não devem precisar dele.

O parâmetro IP é a base 64 do destino do cliente, usando a base I2P 64 – ~ alfabeto. Os destinos são 387+ bytes, com os quais a base 64 é de 516+ bytes. Os clientes geralmente adicionam “.i2p” ao destino básico 64 para manter a compatibilidade com os antigos rastreadores. Os rastreadores não devem ser precisam adicionar “.i2p” no final.

Outros parâmetros são os mesmos que no BitTorrent padrão.

Os destinos I2P atuais para clientes são 387 bytes ou mais (516 ou mais com codificação base64). Um máximo razoável para assumir, por enquanto, é de 475 bytes. Como o rastreador deve decodificar a base64 para produzir respostas compactas (veja abaixo), provavelmente o rastreador deve decodificar e rejeitar a base64 É anunciado.

A resposta do tipo padrão é não compacta. Os clientes podem solicitar uma resposta compacta com o parâmetro compacto = 1. Um trackerpodría, mas não é um requisito, retornando uma resposta compacta quando solicitada.

para novos desenvolvedores de clientes I2P são fortemente encorajados a implementar anúncios sobre seu próprio túnel em vez de sobre o proxy http do cliente na porta 4444. Fazer isso é o mais eficiente e, por sua vez, permite que o rastreador aplique destinos (veja abaixo).

Não há clientes ou rastreadores I2P conhecidos que atualmente suportam respostas de anúncios / UDP.

não -Compact Rastreador respostas

A resposta não compacta é como o BitTorrent padrão, com um “IP” i2p.

Os rastreadores geralmente incluem uma chave de porta falsa ou usam a porta de publicidade , para compatibilidade com clientes anteriores. Os clientes devem ignorar o parâmetro da porta (porta) e não devem solicitá-lo.

O valor da chave IP é a base 64 do destino do cliente, conforme descrito acima. Os rastreadores geralmente adicionam “.i2p” no final do destino básico 64 se não estiver no IP do anúncio, por compatibilidade com clientes anteriores. Os clientes não devem solicitar um sufixo “.i2p” nas respostas.

Outras chaves e valores de resposta são os mesmos que no padrão BitTorrent.

Compact Rastreador respostas

Na resposta compacta, o valor da chave do dicionário dos “pares” é uma única cadeia de bytes, cujo comprimento é um múltiplo de 32 bytes. Esta cadeia contém hashes SHA-256 de 32 bytes concatenados a partir dos destinos binários de pares. Este `hash` (identificador exclusivo) deve ser calculado pelo rastreador, a menos que use o aplicativo no destino (veja abaixo), caso em que o identificador (` hash`) entregue no http x-i2p-destino ou x- Cabeçalhos I2P – Destb32 podem ser convertidos em binário e armazenados. A chave dos pares (‘pares`) pode estar ausente, ou o valor dos pares pode ter comprimento-zero.

Embora o suporte para resposta compacta seja opcional para clientes e rastreadores, é altamente Recomendado, uma vez que reduz o tamanho da resposta nominal cerca de 90%.

Aplicação no destino

Alguns clientes torrent do I2P, embora nem todos, anunciam seus próprios túneis. Os rastreadores podem optar por impedir a fraude exigindo-os e verificando o destino do cliente usando os cabeçalhos adicionados pelo túnel do servidor HTTP i2ptunnel. Os cabeçalhos são X-I2P-Denthash, X-I2P-Dentb64 e X-I2P-DESTB32, que são diferentes formatos para as mesmas informações. Esses cabeçalhos não podem ser distorcidos pelo cliente. Um rastreador exigindo destinos não precisa do parâmetro de anúncio IP.

Como vários clientes usam o proxy HTTP em vez de seus próprios túneis para anúncios, o aplicativo de destino (no rastreador) impedirá que seja usado por aqueles clientes a menos que, ou até que os clientes sejam reconhecidos para anunciar em seus próprios túneis.Infelizmente, por crescer a rede, também fará a quantidade de maliciosidade, por isso esperamos que, no momento em que todos os rastreadores aplicam destinos. Ambos, os desenvolvedores de rastreadores e os clientes devem antecipar.

anúncio Nomes de servidor

Os nomes do servidor URL do anúncio em arquivos torrent, padrões de acompanhamento de nomes I2P. Além dos nomes dos servidores dos livros de endereços e os nomes do servidor base 32 “.b32.i2p”, o destino da base completo 64 (com sufixo “.i2p”] deve ser suportado. Os rastreadores não abertos devem reconhecer seu próprio servidor nomes em qualquer um desses formatos.

Para preservar o anonimato, os clientes geralmente devem ignorar URLs de anúncios não-I2P nos arquivos torrent.

Conexões entre clientes

cliente – Conexões do cliente Use o protocolo padrão no TCP. Atualmente não há clientes i2p conhecidos que suportam comunicação UTP (protocolo de transporte utorrent).

I2P USA Destinos de 387 + bytes para direções, conforme explicado acima.

Se o cliente tiver apenas o identificador criptográfico (`hash`) do destino (como o de uma resposta compacta ou o PEX (Protocolo de Exchange de Peer)), você deve executar uma pesquisa codificando-a com base 32, adicionando o sufixo “.b32.i2p” e consultoria no nome do nome s, o que retornará o destino completo se estiver disponível.

Se o cliente tiver o destino completo de um torque (`” ponto “), ele recebeu em uma resposta não compacta, ele deve usá-lo diretamente o estabelecimento da conexão. Não converter um destino de volta para um identificador criptográfico (`hash`) Base 32, isso é bastante ineficiente.

prevenção cruzada cruzada.

para preservar o anonimato, clientes i2p BitTorrent geralmente não suporta anúncios no-i2p, ou conexões de pares (“pares”). Os proxies no exterior (outproxies`) HTTP do I2P muitas vezes bloqueiam anúncios. Não há proxies no exterior soquetes conhecidos que suportam o tráfego BitTorrent.

Para evitar o uso por clientes no-i2p através de um proxy para dentro (“inproxy`) HTTTT, os rastreadores do I2P geralmente bloqueiam o acesso ao cabeçalho HTTP X- Encaminhado para. Os rastreadores devem rejeitar anúncios de rede padrão com IPv4 ou IPv6 e não entregá-los nas respostas.

O PEX (PEXO PROTOCOLO DE PROCUTO) I2P é baseado no ut_pex (uTorrent PEX). Como não parece ser uma especificação formal UT_PEX, pode ser necessário rever o código-fonte libtorrent para assistência. É uma mensagem de extensão, identificada como “i2p_pex” na extensão do conector de contato (“Handshake”). Ele contém um dicionário codificado B (`BENCODED`) com até 3 teclas,” adicionado “,” adicionado.f “e” cair “(descartado). Os valores “adicionados” e “descartados” são cada uma única cadeia de bytes, cujo tamanho é um múltiplo de 32 bytes. Estas cadeias de byte são os identificadores criptográficos (‘hashes’) SHA-256 concatenados dos destinos binários de pares («pares»). Este é o mesmo formato que os valores do dicionário dos pares no formato de resposta compacto I2P especificado acima. Se presente, o valor do ADEDE.F é o mesmo que no UT_PEX.

DHT

O suporte DHT (tabela Dynamic Hash) está incluído no cliente I2PSNark da versão 0,9.2 . As diferenças preliminares com o BEP 5 (proposta de melhoria do BitTorrent 5) são descritas abaixo e estão sujeitas a alterações. Entre em contato com os desenvolvedores do I2P Se você quiser desenvolver um cliente com suporte ao DHT.

A defesa que DHT (Tabela Dynamic Hash), I2P DHT não usa nenhum bit nas opções de contato (`Handshake`), ou na mensagem de porta (porta). É anunciado com uma mensagem de extensão, identificada como “i2p_dht” na extensão de aperto de mão. Ele contém um dicionário codificado B (`bencoded`) com duas chaves,” porta “e” rport “, tanto inteiros.

A porta UDP (datagrama) listada na informação do nó compacto é usada para receber réplica (Assinado) DataGamps.Este é usado para consultas, exceto para anunciantes.Nós chamamos isso da “porta de consulta”. Este é o valor “porta” da mensagem de extensão.Queries Use i2cprotocolo número 17.

em Além disso, para essa porta UDP, usamos o segundo datagramport igual à porta de consulta + 1. Isso é usado para receber dados de respostas, erro e anúncios. Esta porta fornece uma eficiência incrédula desde que a RepliesContain Tokens enviados na consulta e necessitam Não é assinado. Chamamos isso a “porta de resposta”. Esse é o valor “RPP” da mensagem de extensão.Im deve ser 1 + a porta de consulta.Responsando e anuncia use o i2cprotocolo número 18.

compacto Informações de torque (`Peer`) são 32 bytes (identificador criptográfico (` `hash`) SHA256 32 bytes) em vez de 4 bytes de IP + 2 Porto bytes. Não há porto do par.Em uma resposta, os “valores” (valores) são uma lista de cadeias, cada uma contendo as informações compactas de um único par.

As informações compactas do nó são 54 bytes (20 bytes de Hash Sha1 + 32 bytes de hash sha256 + 2 bytes portuários) em vez de 20 bytes de hash SHA1 + 4 bytes de IP + 2 bytes de porta. Em uma resposta, os “nós” (nós) são uma string de byte única com informações compactadas do nó compacto.

Requisito de identificador (`ID`) Nó Seguro: Para torná-lo mais difícil Diferentes ataques DHT (distribuídos Tabela de hash) Os primeiros 4 bytes do identificador de nó («ID») devem corresponder aos primeiros 4 bytes do identificador criptográfico (`hash`) do destino, e os seguintes 2 bytes do identificador de nó devem corresponder com os próximos 2 bytes do resultado da operação ou exclusiva do hash de destino com o porto.

Em um arquivo torrent, os “nós” da chave do dicionário de uma torrent sem rastreador devem ser determinados. Pode ser uma lista de cadeias binárias de 32 bytes (hashes sha256) em vez de uma lista de listas contendo uma cadeia de servidor e um valor de porta inteira. Alternativas: uma única cadeia de bytes com notas concatenadas, ou uma lista de correntes sozinho.

rastreadores de datagramas (UDP)

Ainda não disponível para clientes e rastreadores (rastreadores BitTorrent) Suporte para rastreadores As diferenças preliminares com o BEP 15 são descritas abaixo, e são susceptíveis de alterar. Entre em contato com os desenvolvedores do I2P, se quiser desenvolver um cliente ou um rastreador que suporte anúncios sobre datagramas.

um tracker udp Ouviste para 2 portas. A “porta de petição” é a porta anunciada e é usada para receber dados respondíveis (assinados), apenas para a solicitação de conexão. A “porta de resposta” é usada para receber datagramas sem assinatura (RAW, RAW) , e é a porta de origem para todas as respostas. A porta de resposta é arbitrária.A cliente envia e recebe exclusivamente em um único porto. Ainda não sinal). Datagramas Propinchão cru Nan maior eficiência para respostas, uma vez que contêm credenciais enviadas na petição e não precisam ser assinadas.

No aplicativo de anúncio, o IP de 4 bytes é substituído por um hash de 32- bytes, e a porta ainda está presente, embora possa ser ignorada pelo rastreador. Na resposta do anúncio, cada porta IP e 2 bytes de 4 bytes, é substituída por um hash (informação compacta de torque) de 32- bytes, sem apresentar qualquer porta . O cliente envia a solicitação de anúncio e a solicitação de raspagem (raspagem, estatísticas de torrent) para a porta de origem do pacote de resposta do anúncio. Solicitação de conexão, resposta de conexão, resposta à conexão, resposta à conexão Rafé, resposta de raspar e resposta de erro, são O mesmo que na (Proposição de Melhoria de BitTorrent) BEP 15.

Os endereços de origem no I2P não podem ser falsificados, portanto, é possível usar um protocolo simplificado 2 pacotes atingem 4, omitindo a solicitação de conexão e a resposta. este caso, th E anunciar solicitação seria um datagrama de replays enviado para a porta de consulta do rastreador, e o rastreador não exigiria uma porta de resposta. Que isso for mais eficiente, seria mais difícil modificar um rastreador existente para suportar este modo. O URL para o 4-Packet-Mode Tracker usaria prefixo padrão “UDP: //”. O URL para um rastreador de modo de 2 pacotes modificados exigiria prefixo diferente se ambos os modos forem sujeitos no I2P.

Informações adicionais

/ h2>

os padrões de I2P de BitTorrent são geralmente discutidos no ZZZ.I2P.
• Um gráfico com os recursos do software atual do rastreador também está disponível lá.
• FAQ do BitTorrent I2P
• Discusion do DHT sobre I2P