Hai varios clientes de BitTorrent e Trackers en I2P. Como o enderezo I2P usa un destino en vez de IP e porto, os cambios que son necesarios no rastreador e o software cliente para operar en I2P son menores. Estes cambios están especificados a continuación. Observe coidadosamente as pautas para a compatibilidade cos clientes e seguidores anteriores i2p.
Esta páxina especifica detalles do protocolo común a todos os clientes e seguidores. Os clientes e os rastreadores específicos poden implementar outras características ou protocolos únicos.
Os portos de software de clientes e rastreadores adicionais son benvidos para i2p
anuncios
Os clientes adoitan incluír un porto de parámetro falso = 6881 No anuncio, por compatibilidade con seguidores anteriores. Os seguidores poden ignorar o parámetro do porto (porto) e non o necesitan.
O parámetro IP é a base 64 do destino do cliente, usando a base I2P 64 – ~ alfabeto. Os destinos son 387+ bytes, cos que a base 64 é de 516+ bytes. Os clientes xeralmente engaden “.I2P” ao destino base 64 para manter a compatibilidade con antigos seguidores. Os seguidores non deben engadir “.I2P” ao final.
Outros parámetros son os mesmos que o estándar BitTorrent.
Os destinos de I2P actuais para os clientes son 387 bytes ou máis (516 ou máis con codificación Base64). Un máximo razoable para asumir, por agora, é de 475 bytes. Como o rastreador debe decodificar a base64 para producir respostas compactas (ver a continuación), probablemente o rastreador debe decodificar e rexeitar a base64 errónea cando este Anúnciase.
A resposta por defecto é non compacta. Os clientes poden solicitar unha resposta compacta co parámetro compacto = 1. Unha trackerpodría, pero non é un requisito, devolver unha resposta compacta cando se solicita.
a novos desenvolvedores de clientes I2P son firmemente alentados a implementar anuncios sobre o seu propio túnel no canto do proxy do cliente HTTP no porto 4444. Facelo é tanto máis eficiente e á súa vez, permite que o rastreador poida aplicar destinos (consulte a continuación).
Non hai clientes ou coñecidos seguidores de I2P que actualmente soportan as respostas de anuncios / UDP.
NON -Compact Tracker respostas
A resposta non compacta é como o estándar BitTorrent, cun “IP” i2p.
Os seguidores xeralmente inclúen unha chave do porto falso ou usar o porto de publicidade , por compatibilidade cos clientes anteriores. Os clientes deben ignorar o parámetro do porto (porto) e non deben solicitalo.
O valor da clave IP é a base 64 do destino do cliente, como se describe anteriormente. Os seguidores xeralmente engaden “.I2P” ao final do destino base 64 se non estaba no IP do anuncio, por compatibilidade cos clientes anteriores. Os clientes non deben solicitar un sufijo “.I2P” nas respostas.
Outras claves e valores de resposta son iguais ao estándar de BitTorrent.
Rastreador compacto
Na resposta compacta, o valor da chave do dicionario dos “pares” é unha única cadea de bytes, cuxa lonxitude é un múltiplo de 32 bytes. Esta cadea contén haches SHA-256 de 32 bytes concatenados dos destinos de pares binarios. Este `hash` (identificador único) debe calcularse polo rastreador, a menos que utilice a aplicación no destino (ver a continuación), nese caso o identificador (` hash`) entregado no HTTP X-I2P-Desthash ou X- Os encabezados I2P -DestB32 pódense converter a binarios e almacenados. A chave dos pares (`pares`) pode estar ausente, ou o valor dos pares pode ter lonxitude-cero.
Aínda que o soporte para a resposta compacta é opcional para clientes e rastreadores, é altamente Recomendado xa que reduce o tamaño da resposta nominal ao redor do 90%.
Aplicación no destino
Algúns clientes de Torrent de I2P, aínda que non todos, anuncian os seus propios túneles. Os seguidores poden optar por evitar a trampas esixindo-los e verificar o destino do cliente usando os encabezados engadidos polo túnel do servidor HTTP i2PTunnel. Os encabezados son x-i2p-dtentah, x-i2p-dentb64 e x-i2p-destb32, que son diferentes formatos para a mesma información. Estes cabeceiras non poden ser distorsionados polo cliente. Un rastreador que esixe destinos non necesita o parámetro de anuncio de IP.
Como varios clientes usan o proxy HTTP en lugar dos seus propios túneles para anuncios, a aplicación de destino (no rastreador) evitará o seu uso por aqueles Clientes a menos que, ou ata que os clientes se volven a anunciar nos seus propios túneles.
Por desgraza, crecendo a rede, tamén o fará a cantidade de malicia, polo que esperamos que no momento en que todos os seguidores apliquen destinos. Os dous desenvolvedores e clientes de Trackers deben anticipar-lo.
Nomes do servidor de anuncios
Os nomes dos servidores de anuncios de URL en ficheiros de torrent, estándares de seguimento de nomes I2P. Ademais dos nomes dos servidores dos libros de enderezos e os nomes do servidor base 32 “.b32.i2p”, debe ser compatible co destino completo de base 64 (con sufijo “.I2P”]. Os seguidores non abertos deben recoñecer o seu propio servidor Nomes en calquera destes formatos.
Para preservar o anonimato, os clientes adoitan ignorar os URLs de anuncios non I2P nos ficheiros de torrent.
conexións entre os clientes
Cliente -Poder as conexións do cliente Use o protocolo estándar en TCP. Actualmente non hai clientes de I2P que admiten a comunicación UTP (Protocolo de transporte de uTorrent).
Destinos de I2P de Estados Unidos de 387 + bytes para indicacións, como se explica anteriormente.
Se o cliente ten só o identificador criptográfico (`hash`) do destino (como a dunha resposta compacta ou o PEX (protocolo de intercambio peer)), debe realizar unha busca codificándoa con base 32, engadindo o sufijo “.b32.i2p” e consultando no servizo de nome S, que devolverá o destino completo se está dispoñible.
Se o cliente ten o destino completo dun torque (`peer`) que recibiu nunha resposta non compacta, debe usalo directamente o establecemento da conexión. Non converte un destino de volta a un identificador criptográfico (`hash`) base 32, isto é bastante ineficiente.
Prevención de cruzamento cruzado.
Para preservar o anonimato, os clientes i2p BitTorrent xeralmente non soporta anuncios NO-I2P ou conexións de pares (`pares`). Os proxies no estranxeiro (outproxies`) HTTP de i2p a miúdo bloquean anuncios. Non hai proxies no estranxeiro coñecidos sockets que soportan o tráfico de BitTorrent.
para evitar o uso dos clientes de NO-I2P a través dun proxy cara a dentro (“Inproxy`) HTTTT, os seguidores de I2P a miúdo bloquean os anuncios que conteñen un encabezado HTTP X- Reenviado por. Os seguidores deben rexeitar os anuncios de rede estándar con IPv4 ou IPv6 e non entregarlles nas respostas.
O PEX (Protocolo de intercambio de pares) I2P está baseado en UT_PEX (uTorrent PEX). Como non parece haber unha especificación formal de UT_PEX, pode ser necesario revisar o código fonte de LiBTorrent para obter asistencia. É unha mensaxe de extensión, identificada como “i2p_pex” na extensión de Jack de contacto (`Handshake`). Contén un dicionario b-codificado (‘bencoded`) con ata 3 teclas, “engadido”, “engadido.f” e “caeu” (descartado). Os valores “engadidos` e` caen” son cada unha dunha única cadea de bytes, cuxo tamaño é un múltiplo de 32 bytes. Estas cadeas de bytes son os identificadores criptográficos (‘hashes’) SHA-256 concatenates dos destinos de pares binarios (`pares`). Este é o mesmo formato que o dos valores do dicionario dos pares do formato de resposta compacto I2P especificado anteriormente. Se está presente, o valor de Adede.f é o mesmo que en UT_PEX.
DHT
O soporte DHT (Dynamic Hash Table) está incluído no cliente i2psnark da versión 0.9.2 .. As diferenzas preliminares co BEP 5 (proposta de mellora de BitTorrent 5) descríbense a continuación e están suxeitas a cambios. Póñase en contacto cos desenvolvedores I2P se quere desenvolver un cliente con soporte de DHT.
A defensa que DHT (Dynamic Hash Table), I2P DHT non usa ningún pouco nas opcións de contacto (`Handshake`) ou Na mensaxe do porto (porto). Anúnciase cunha mensaxe de extensión, identificada como “I2P_DHT” na extensión de axuste de man. Contén un dicionario codificado b (‘bencoded`) con dúas teclas, “porto” e “rport”, ambos enteiros.
O porto UDP (datagrama) que figura na información do nodo compacto é usado para recibir a réplica (Firmado) DataGamps.This úsase para consultas, excepto por anuncia. Chame a este o “porto de consulta”. Este é o valor do “porto” da extensión Message.Queries usa o número I2CProtoCol Ademais do porto UDP, usamos a segunda datagramport igual ao porto de consulta + 1. Isto úsase para recibir datos (RAW) de datos para respostas, erro e anuncia. Este porto proporciona unha eficiencia incrustada xa que a repliescontain Non se asinou. Chamamos a este o “porto de resposta”. Este é o valor “Rport” da mensaxe de extensión. Debe ser 1 + o porto de consulta e anuncia o uso do número I2CProtoCol 18.
compacto A información de torque (`peer`) son de 32 bytes (identificador criptográfico (` hash`) SHA256 32 bytes) en vez de 4 bytes de IP + 2 Porto bytes. Non hai ningún porto da parella.Nunha resposta, os “valores” clave (valores) son unha lista de cadeas, cada unha que contén a información compacta dun único par.
A información do nodo compacto é de 54 bytes (20 bytes de Hash SHA1 + 32 Bytes of Hash SHA256 + 2 porto bytes) en lugar de 20 bytes de Hash SHA1 + 4 bytes de IP + 2 bytes de porto. Nunha resposta, a chave “nodos” (nodos) é unha única cadea de byte con información compatible de nodos compatible.
Requisito do identificador (`ID`) Nodo seguro: para que sexa máis difícil de ataques DHT (distribuídos) Táboa de hash) Os primeiros 4 bytes do identificador de nodos (`id`) deben coincidir cos primeiros 4 bytes do identificador criptográfico (` hash`) do destino e os seguintes 2 bytes do identificador de nodos deben coincidir cos próximos 2 bytes do resultado da operación ou exclusiva do hash de destino co porto.
Nun ficheiro torrent, a chave “nodos” do dicionario dun torrente sen rastrexar ten que ser determinado. Podería ser unha lista de cadeas binarias de 32 bytes (HASHAS SHA256) no canto dunha lista de listas que conteñen unha cadea de servidor e un valor de porto enteiro. Alternativas: unha única cadea de bytes con cualificacións concatenadas ou unha lista de cadeas só.
Datagrams Trackers (UDP)
Aínda non está dispoñible para os clientes e seguidores (seguidores BitTorrent) UDP.The diferenzas preliminares co BEP 15 descríbense a continuación e son susceptibles de cambiar. Póñase en contacto cos desenvolvedores de I2P se desexa desenvolver un cliente ou un seguidor que admita anuncios sobre datagramas.
un rastreador UDP escoita a 2 portos. O “porto de petición” é o porto anunciado e úsase para recibir datos de resposta (asinado), só para a solicitude de conexión. O “porto de resposta” úsase para recibir datagramas sen firme (en bruto, en bruto) , e é o porto de orixe para todas as respostas. O porto de resposta é arbitrario. Un cliente envía e recibe exclusivamente nun único porto. Aínda non ten sinalización). Datagrams Propiación Raw NAN maior eficiencia para as respostas, xa que conteñen credenciais enviadas na petición e non hai que ser asinado.
Na aplicación de anuncio, a IP de 4 bytes é substituída por un hash de 32 bytes, E o porto aínda está presente, aínda que pode ser ignorado polo rastreador. Na resposta publicitaria, cada porto IP de 4 bytes e 2 bytes, substitúese por un hash (información compacta de torque) de 32 bytes, sen presentar ningún porto . O cliente envía a solicitude de publicidade e a solicitude de raspa (raspado, estatísticas de torrent) ao porto de orixe do paquete de resposta de anuncios. Solicitude de conexión, resposta de conexión, resposta de conexión, raspar a resposta da conexión, a resposta de raspar e a resposta de erro, é a igual que na (proposta de mellora de BitTorrent) BEP 15.
Enderezos de orixe en i2p non se pode falar, polo que é posible usar un protocolo simplificado 2 paquetes involuntarios de 4, omitindo a solicitude de conexión e resposta. En Este caso, th E anunciar a solicitude sería unha reprodución Datagram enviada ao porto de consulta do rastreador e que o rastreador non requiriría un porto de resposta. Mentres isto é máis eficiente, sería máis difícil modificar un seguidor existente para soportar este modo. O URL do 4-Packet-Mode Tracker usaría o prefixo estándar “UDP: //”. O URL para un rastreador de modo de 2 paquetes modificado requiriría un prefixo diferente se ambos os modos están suportados en i2p.
Información adicional
- Os estándares de BitTorrent i2P son xeralmente discutidos en zzz.i2p.
- Un gráfico coas capacidades do software de seguimento actual tamén está dispoñible alí.
- o Preguntas frecuentes do BitTorrent I2P
- Discusión de DHT SOBRE I2P