msgstr "L’implémentation du principal client I2P utilise Java. Si pour certaines raisons vous ne pouvez pas utiliser Java sur votre dispositif, il y a des implémentations alternatives développées par des membres de la communauté."
msgstr "<a href=\"%(i2pd)s\">i2pd</a> est une implémentation de client I2P écrite en C++.\nDébut 2016, i2pd est devenu suffisamment stable pour être utilisable en production, et depuis l’été 2016 il implémente complètement toutes les APIs d’I2P."
"<a href=\"%(golang)s\">Go</a> programming language. The project is in early development."
msgstr "<a href=\"%(go_i2p)s\">Go-I2P</a> est un client I2P client développé en utilisant le langage de programmation \n<a href=\"%(golang)s\">Go</a>. Le projet est au début de son développement."
msgstr "Votre navigateur web devra être configuré pour pouvoir naviguer sur les eepsites et\nutiliser les outproxies disponibles dans I2P. Voici les procédures pour certains des\nnavigateurs les plus populaires."
msgstr "Dans le menu Outils, sélectionner la ligne « Options Internet » pour ouvrir les paramètres. Dans la fenêtre des paramètres, choisir l’onglet Connexions et cliquer sur les paramètres du réseau local pour la configuration du port du mandataire."
"<b>Note/Privacy tip:</b> Set the FTP proxy to the same settings as the HTTP proxy."
msgstr "Maintenant, cochez « utiliser un serveur mandataire pour votre réseau local » et « Ne pas utiliser de serveur mandataire pour les adresses locales ». Cliquez sur le bouton Évolué afin d’ouvrir les ports. Saisissez les valeurs telles que sur l’image, IP 127.0.0.1 et port 4444 pour HTTP, port 4445 pour HTTPS. Cliquez sur OK pour enregistrer les paramètres. Votre navigateur est prêt à utiliser le mandataire I2P.\n<b>Note/astuce de confidentialité :</b> définissez le mandataire FTP aux mêmes paramètres que le mandataire HTTP."
msgstr "Dans le menu Outils, sélectionnez Options pour faire apparaître le panneau de configuration de Firefox.\nCliquez sur l’icône <em>Évolué</em> puis sur l’onglet <em>Réseau</em>.\nDans la section <em>Connexions</em>, cliquez sur le bouton Paramètres. Vous verrez une fenêtre comme celle-ci :"
"<b>Note/Privacy tip:</b> Set the FTP proxy to the same settings as the HTTP proxy."
msgstr "Dans la fenêtre <em>Paramètres de connexion</em>, cliquer sur le cercle situé à côté du champ <em>Configuration manuelle du mandataire.</em>, puis saisir 127.0.0.1, port 4444 dans le champ du mandataire HTTP. Saisir 127.0.0.1, port 4445 dans le champ du mandataire SSL.\nS’assurer de saisir localhost et 127.0.0.1 dans la boîte « Aucun mandataire pour ».\n<b>Note/astuce confidentialité :</b> définir le mandataire FTP avec les mêmes paramètres que le mandataire HTTP."
msgstr "Dans le menu <em>Paramètres</em>, sélectionner <em>Configurer Konqueror</em>. Dans le groupe Navigation Web situé à gauche, sélectionner Mandataire, puis sélectionner l’option « Utiliser une configuration de mandataire indiquée manuellement »."
"<b>Note/Privacy tip:</b> Set the FTP proxy to the same settings as the HTTP proxy."
msgstr "Saisir 127.0.0.1 et port 4444 dans la boîte HTTP. Saisir 127.0.0.1 et port 4445 dans la boîte HTTPS. Saisir <code>127.0.0.1,localhost</code> dans la boîte Exceptions. Cliquer sur Appliquer puis sur OK pour fermer la fenêtre de configuration.\n<b>Note/astuce confidentialité :</b> définir le mandataire FTP avec les mêmes paramètres que le mandataire HTTP."
msgstr "Se souvenir : I2P n’a pas été conçu pour créer des mandataires vers l’Internet externe.\nIl est plutôt destiné à être utilisé comme réseau interne."
msgstr "<p><b>Le projet I2P même n’exploite aucun mandataire vers Internet.</b> \nLe seul mandataire sortant est un service du projet par « Privacy Solutions ». \nEnvisagez de leur faire un don afin de garantir un service stable et continu. La bande passante augmentera en proportion du financement de l’organisation. Et peut-être aussi plus de mandataires sortants.</p>\n<a href=\"http://privacysolutions.no\"\ntarget=\"_blank\">http://privacysolutions.no</a>"
msgstr "Par défaut, I2P est fourni avec deux proxy sortants pré-configurés : <code>%(http)s</code> \net <code>%(https)s</code>. Même si les noms de domaine sont différents, c’est le même proxy sortant que vous atteignez.\n(multi domiciles/clés afin d’obtenir de meilleures performances)"
msgstr "Ces mandataires sortants appliquent des filtres (par exemple, mibbit et l’accès aux traqueurs de torrents sont bloqués). Les sites eep sont accessibles par des adresses .i2p ne sont pas non plus autorisés par les mandataires sortants.\nPar commodité, le mandataire sortant bloque les serveurs de publicités."
msgstr "Si vous avez fait un don, veuillez envoyer un courriel à <a href=\"mailto:%(echelon)s\">echelon</a> avec votre nom ou pseudo (et facultativement votre page Web) afin que nous puissions vous lister ici."
"All communication is end to end encrypted (in total there are four layers of \n"
"encryption used when sending a message), and even the end points (\"destinations\") \n"
"are cryptographic identifiers (essentially a pair of <a href=\"%(pke)s\">public keys</a>)."
msgstr "I2P un réseau anonyme, exposant une couche simple que les applications peuvent\nutiliser afin d’envoyer anonymement et en sécurité des messages de l’une à l’autre. Le réseau lui-même est\nstrictement basé message (à la <a href=\"%(ip)s\">IP</a>), mais il y a\nune bibliothèque disponible permettant la communication fiable en continu au-dessus de cela (à la\n<a href=\"%(tcp)s\">TCP</a>).\nToute la communication est chiffrée de bout en bout (au total il y a quatre couches de\nchiffrement utilisées lors de l’envoi d’un message) et même les points de fin (\"destinations\")\nsont des identifiants cryptographiques (essentiellement une paire de <a href=\"%(pke)s\">clés publiques</a>)."
msgstr "Pour anonymiser les messages envoyés, chaque application cliente fait construire à son \"routeur\" I2P\nquelques \"<a href=\"%(tunnelrouting)s\">tunnels</a>\" entrants et sortants - une\nséquence de pairs qui passent des messages dans un sens (vers et à partir du client,\nrespectivement). À son tour, quand un client veut envoyer un message à un autre client,\nle client transmet ce message dans l’un des tunnels sortants en ciblant l’un des\ntunnels entrants d’un autre client, pour finalement atteindre la destination. Chaque\nparticipant au réseau choisit la longueur de ses tunnels, et, ce faisant,\nfait un compromis entre anonymat, latence, et débit, en fonction de leurs\nbesoins propres. Le résultat est que le nombre de pairs relayant chaque message\nd’extrémité en extrémité soit le strict minimum nécessaire pour répondre au modèle de menace\nà la fois de l’expéditeur et du récepteur."
msgstr "La première fois qu’un client veut en contacter un autre, ils envoient une requête à la « <a href=\"%(netdb)s\">base de données du réseau</a> », entièrement distribuée, une <a href=\"%(dht)s\">table de hachage distribuée (DHT)</a> à structure personnalisée fondée sur <a href=\"%(kad)s\">l’algorithme Kademlia</a>. Cela est fait afin de trouver efficacement les « tunnels entrants » de l’autre client. Les messages subséquents qu’ils échangent incluant habituellement ces données, aucune autre consultation de la base de données de réseau n’est nécessaire."
msgstr "Dans le réseau I2P, les applications ne sont pas restreintes dans la façon dont elles peuvent\ncommuniquer - celles qui utilisent habituellement UDP peut faire usage de la fonctionnalité I2P\nde base, et celles qui utilisent généralement TCP peuvent utiliser la bibliothèque streaming\nfaçon-TCP. Nous avons une application de pont TCP/I2P générique (\"<a href=\"%(i2ptunnel)s\">I2PTunnel</a>\") qui permet aux gens de transmettre des flux TCP\nvers le réseau I2P ainsi que de recevoir des flux depuis le réseau et\nde les transmettre vers une adresse TCP/IP spécifique."
msgstr "I2PTunnel est utilisé actuellement pour permettre aux utilisateurs de faire tourner leur propre site Web anonyme (« site eep ») en faisant fonctionner un serveur Web normal et en dirigeant un « serveur » I2PTunnel vers ce dernier, serveur accessible anonymement par I2P avec un navigateur Internet normal en exécutant un mandataire HTTP I2PTunnel (« mandataire eep »). De plus, nous utilisons la même technique pour faire fonctionner un réseau IRC anonyme (où le serveur IRC est hébergé anonymement et sur lequel les clients IRC normaux utilisent un I2PTunnel pour le contacter).\nD’autres efforts de développement d’applications existent aussi, comme la construction d’une application optimisée de transfert segmenté de fichiers (semblable à <a href=\"%(bittorrent)s\">BitTorrent</a>), un magasin de données distribué (semblable à <a href=\"%(freenet)s\">Freenet</a> ou <a href=\"%(mnet)s\">MNet</a>), et un système de blogage (un\n<a href=\"%(livejournal)s\">« LiveJournal »</a> entièrement distribué), mais elles ne sont pas encore prêtes à être utilisées."
msgstr "I2P n’est pas en lui-même un réseau \"proxy sortant\" - le client auquel vous envoyez un message\nest l’identifiant cryptographique, pas une certaine adresse IP, donc le message doit \nêtre adressé à quelqu’un exécutant I2P. Cependant, il est possible pour ce client\nd’être un proxy sortant, vous permettant de vous servir anonymement de sa connexion\nInternet. Pour démontrer ceci, le \"eepproxy\" va accepter des URL normales non-I2P\n(par exemple \"http://www.i2p.net\") et les expédier à une destination spécifique\nqui exécute un proxy HTTP <a href=\"%(squid)s\">squid</a>, permettant\nainsi simplement la navigation anonyme sur le web normal. De simples proxys sortants comme ceci \nne sont pas viables à long terme pour plusieurs raisons (incluant le coût d’en faire tourner\nun aussi bien que l’anonymat et les problèmes de sécurité qu’ils introduisent), mais dans\ncertaines circonstances cette technique est parfois appropriée."
msgstr "L’<a href=\"%(team)s\">équipe</a> de développement I2P est un groupe ouvert, bienvenue à tous\nceux qui sont intéressés à <a href=\"%(volunteer)s\">s’impliquer </a>, et tout\nle code est <a href=\"%(licenses)s\">open source</a>. Le noyau I2P SDK et\nla mise en œuvre actuelle du routeur sont faites en Java (qui marche actuellement avec\nsun et kaffe, support gcj prévu pour plus tard), et il y a une\n<a href=\"%(sam)s\">API basée sur socket simple</a> pour accéder au réseau depuis\nd’autres langages (avec une bibliothèque en langage C, tandis que Python et Perl sont\nendéveloppement). Le réseau est activement développé et n’a pas encore atteint\nla version 1.0, cependant la <a href=\"%(roadmap)s\">feuille de route</a> actuelle décrit\nnotre calendrier."
"Following are links to presentations, videos, and tutorials about I2P. Links"
" to research papers on I2P are available <a href=\"%(papers)s\">here</a>."
msgstr "Ce qui suit sont des liens vers des présentations, des vidéos et des tutoriels sur I2P. Des liens vers des documents de recherche sur I2P sont disponibles <a href=\"%(papers)s\">ici</a>."
msgstr "Présentation IIP à Codecon\n<a href=\"%(mp3)s\">audio MP3</a>\n<a href=\"%(transcript)s\">transcription</a>\nLance James (0x90), février 2002."
msgstr "<a href=\"%(video)s\">To Be or I2P</a>\n(vidéo Youtube)\nUne introduction à la communication anonyme avec I2P.\n<a href=\"%(pdf)s\">To Be or I2P (PDF de la présentation)</a>,\nJens Kubieziel, 24C3 Berlin, le 28 décembre 2007."
msgstr "HOPE New York, 17 juillet 2010 - Brève présentation d’I2P par zzz, à la fin de l’exposé de Adrian Hong\n«Les bouilleurs pour les droits de la personne» (en anglais).\n<a href=\"%(mp3)s\">audio MP3 </a>"
msgstr "<a href=\"%(link)s\">Utiliser la technologie pour faire avancer la liberté</a>\n(vidéo Youtube)\nEric Johnson. \n<a href=\"http://agora.io/etienne\">Agora I/O Unconference</a>, le 27 mars 2011. \nI2P couvert de 10:00 à 20:00 dans la vidéo."
msgstr "<a href=\"%(live)s\"> Cipherspaces / Darknets : un aperçu des stratégies d’attaque -\nDEF CON Live version (vidéo Youtube) </a>,\n<a href=\"%(studio)s\">Version \"Studio\" (vidéo Youtube) </a>,\n<a href=\"%(slides)s\">Diaporama (ppt)</a>\nAdrian Crenshaw. DEF CON 19, Las Vegas, 7 août 2011."
"echelon, 32C3 (You Broke the Internet Assembly), Hamburg, December 28, 2015"
msgstr "<a href=\"%(link)s\">I2P - Still alive! (pdf)</a>\n<a href=\"%(link2)s\">(vidéo)</a>\nechelon, 32C3 (You Broke the Internet Assembly), Hamburg, 28 décembre 2015"
msgstr "Remplacement de crypto usée (anglais: Weary) : mise à niveau du réseau I2P avec des primitives plus fortes\n<a href=\"%(link)s\">(pdf)</a>\n<a href=\"%(link2)s\">(odp)</a>\nstr4d, Real World Crypto, Stanford, 8 janvier 2016"
"str4d, COMPSCI 460: Computer Networking, University of Wisconsin Whitewater, February 17, 2016"
msgstr "Onions and Garlic: the protocols of I2P\n<a href=\"%(link)s\">(pdf)</a>\n<a href=\"%(link2)s\">(odp)</a>\nstr4d, COMPSCI 460: Computer Networking, University of Wisconsin Whitewater, 17 février 2016"
msgstr "Le projet de l’Internet invisible — Une vue d’ensemble et un guide des technologies\n<a href=\"%(link)s\">(mp4)</a>\n<a href=\"%(link2)s\">(webm)</a>\nAndrew Savchenko (bircoph), FOSDEM, Bruxelles, le 4 février 2018"
msgstr "<a href=\"%(link)s\">Tutoriel I2P sous Debian</a>\n(vidéo Youtube)\nCe tutoriel vous guidera dans l’installation d’I2P sur un système Linux Debian.\nPar <a href=\"http://telecomix.org/\">Telecomix</a>"
msgstr "<a href=\"%(link)s\">Comment mettre en place un site anonyme dans I2P</a>\n(vidéo Youtube)\nComment mettre en place un site web anonyme dans I2P.\nPar <a href=\"http://telecomix.org/\">Telecomix</a>"
msgstr "<a href=\"%(link)s\">Tutoriel I2P Mac OS X</a>\n(vidéo Youtube)\nUn tutoriel sur la façon d’exécuter I2P sur Mac OS X et comment se connecter à irc.telecomix.i2p.\nPar <a href=\"http://telecomix.org/\">Telecomix</a>"
msgstr "<a href=\"%(link)s\">Felix Atari explique les principes de base d’I2P</a>\n(vidéo YouTube)\nAgent Felix Atari du «Telecomix Crypto Munitions Bureau».\nPar <a href=\"http://telecomix.org/\">Telecomix</a>"
"This tutorial shows how to install and configure software needed to access I2P."
msgstr "<a href=\"%(link)s\"> Comment aller sur I2P, le darknet P2P anonyme (installeur Windows) </a>\n(vidéo Youtube)\nCe tutoriel montre comment installer et configurer le logiciel nécessaire pour accéder à I2P."
"(link dead, seeded inside I2P at <a href=\"http://tracker2.postman.i2p/index.php?view=TorrentDetail&id=14336\">postman's tracker</a>)"
msgstr "<a href=\"%(mp3)s\">zzz interviewé lors du InfoSec Daily Podcast Ep. 454 (mp3)</a>\n18 août 2011\n(lien mort, téléchargeable dans I2P via le <a href=\"http://tracker2.postman.i2p/index.php?view=TorrentDetail&id=14336\">tracker de Postman</a>)"
"(link dead, seeded inside I2P at <a href=\"http://tracker2.postman.i2p/index.php?view=TorrentDetail&id=15905\">postman's tracker</a>)"
msgstr "<a href=\"%(mp3)s\">zzz et Lance James interviewés lors du InfoSec Daily Podcast Ep. 596 (mp3)</a>\n16 février 2012\n(lien mort, téléchargeable dans I2P via le <a href=\"http://tracker2.postman.i2p/index.php?view=TorrentDetail&id=15905\">tracker de Postman</a>)"
msgstr "Nous sommes un petit groupe disséminé sur tous les continents qui travaille\nà l’amélioration des différents aspects du projet et qui étudie et débat sur la\nconception du réseau.\n<a href=\"%(volunteer)s\">Impliquez-vous !</a>"
msgstr "I2PCon 2015 était le premier événement de cet type. Il avait deux objectifs à court terme.\nD’abord, de fournir au grand public un événement où il pourrait obtenir de la connaissance au sujet de la vie privée.\nDeuxièmement, à prolonger le projet I2P et sa communauté avec des discussions techniques au sujet de la cryptographie, l’anonymat et les sujets centrés sur I2P."
"commnutiy of privacy-conscious individuals. By connecting people who recognize\n"
"the importance of privacy, we wanted to provide a forum where this community can grow."
msgstr "Un objectif plus grand et à plus à long terme de cet événement était de construire une communauté d’individus conscients de la vie privée. En connectant des gens qui reconnaissent l’importance de la vie privée, nous avons voulu fournir un forum où cette communauté peut croître."
msgstr "L’idée de cet événement a été d’abord engendré par nos merveilleux amis du\n<a href=\"https://torontocrypto.org/\">Toronto Crypto</a>.\nLe lieu a été fourni par <a href=\"https://hacklab.to/\">Hacklab.to</a>.\nLe marketing a été mené par <a href=\"https://twitter.com/YrB1rd\">@YrB1rd</a> et Siew.\nSans eux cet événement n’aurait pas été possible."
msgstr "Colin Mahns a un grand intérêt dans l’utilisation de l’anonymat et de la technologie de chiffrement pour aider à préserver les droits humains à l’âge numérique."
"David Dagon is a postdoc researcher at Georgia Tech focused on botnets, malware, network security, and DNS.\n"
"His interest in I2P is centered on preserving user privacy, autonomous filtering, and anti-abuse."
msgstr "David Dagon est un chercheur post doctorat à Georgia Tech, concentré sur les botnets, les logiciels malveillants, la sécurité de réseau et les DNS.\nSes centres d’intérêt concernant I2P sont la préservation de la vie privée de l’utilisateur, le filtrage autonome, et l’anti-abus."
"He's been focused on network security, malware research, and information security ever since.\n"
"During 2011-2013, he was Director of Threat Intelligence for The Vigilant, which was acquired by Deloitte in 2013.\n"
"He recently left Deloitte to do consulting through his company The James Group."
msgstr "Lance James est le fondateur du projet IRC Invisible, le prédécesseur d’I2P, lancé en 2002.\nIl a fondé sa propre entreprise d’intelligence en cyber menace en 2003. \nDepuis, il a été concentré sur la sécurité de réseau, la recherche concernant le logiciel malveillant et la sécurité de l’information.\nDurant 2011-2013, il était le directeur d’intelligence de menace pour The Vigilant, qui a été acquis par Deloitte en 2013.\nIl a récemment quitté Deloitte pour effectuer du conseil via son entreprise James Group."
"Nicholas Johnston is a Professor of Information Security in Sheridan College's School of Applied Computing in the InfoSec Bachelor's degree program.\n"
"His previous professional career was in digital forensics and investigations.\n"
msgstr "Nicholas Johnston est un professeur de sécurité de l’information au \"Sheridan College’s School of Applied Computing\" dans le programme de licence d’InfoSec. Sa carrière professionnelle précédente était dans la science légale numérique et les enquêtes. Il est aussi un entrepreneur se spécialisant dans la réponse à l’incident. Ses zones de recherche incluent le développement logiciel sécurisé et l’analytique de données."
msgstr "Il existe quelques techniques principales qui peuvent être appliquées pour améliorer les performances perçues d’I2P. Certaines des suivantes sont liées à l’UCT, d’autres à la bande passante et d’autres encore au protocole. Cependant, toutes ces dimensions affectent la latence, le débit, et les performances perçues du réseau, car elles réduisent les conflits pour des ressources rares. Cette liste n’est bien sûr pas complète, mais elle couvre les techniques principales observées."
msgstr "Une des parties probablement les plus importantes pour obtenir la performance plus rapide sera\nd’améliorer comment les routeurs choisissent les pairs( au travers desquels ils construisent leurs tunnels -\nen s’assurant qu’ils n’utilisent pas de pairs avec des liens lents ou avec des liens rapides qui\nseraient surchargés, etc. De plus, nous devons nous assurer que nous ne nous exposons pas\nnous-mêmes à une attaque <a href=\"%(sybilpdf)s\">Sybil</a>\nlancée depuis un adversaire puissant avec beaucoup de machines rapides."
msgstr "Nous allons vouloir être plus efficaces en guérissant la base de données de réseau\net les algorithmes de maintenance - plutôt que constamment explorer le keyspace pour de nouveaux\npairs - cause d’un nombre important de messages de réseau et de charge de routeur - nous\npouvons ralentir ou peut même arrêter d’explorer jusqu’à ce que nous détections qu’il y a\nquelque chose de nouveau méritant d’être trouvé (ex: dégrader le taux d’exploration en se basant sur la dernière fois que quelqu’un nous a donné une référence de quelqu’un dont nous n’avions jamais entendu parler). Nous pouvons aussi faire certains\nréglages sur ce que nous envoyons actuellement - sur combien de pairs nous rebondissons (ou même si nous\nrebondissons en retour une réponse), aussi bien que combien de recherches simultanées nous accomplissons."
msgstr "La façon dont l’algorithme <a href=\"%(elgamalaes)s\">ElGamal/AES+SessionTag</a>\nfonctione est en gérant un ensemble de tableaux de 32 octets à usage unique, et en\nles faisant expirer s’ils ne sont pas utilisés assez rapidement. Si nous les faisons expirer trop tôt, nous\nsommes obligés de nous replier en ayant recours à un (coûteux) plein chiffrement ElGamal, mais si nous ne\nles faisons pas expirer assez rapidement, nous devons réduire leur quantité pour que nous ne soyons pas \nà court de mémoire (et si le destinataire est d’une façon ou d’une autre corrompu et perd certaines étiquettes, encore plus d’échecs de chiffrement peuvent se produire avant la détection). Avec une certaine détection plus active et\ndes algorithmes de retour d’information, nous pouvons sans risque et plus efficacement ajuster la durée de vie des étiquettes, remplaçant le chiffrement ElGamal avec une insignifiante opération AES."
msgstr "Des idées supplémentaires pour améliorer la livraison d’étiquette de session (Session Tag) sont décrites sur la\n<a href=\"%(elgamalaes)s#future\">page ElGamal/AES+SessionTag page</a>."
msgstr "Dès maintenant, notre algorithme <a href=\"%(elgamalaes)s\">ElGamal/AES+SessionTag</a> \nfonctionne en étiquetant chaque message chiffré avec un nonce unique aléatoire \nde 32 octets (une \"étiquette de session\"), identifiant ce message comme étant chiffré \navec la clé de la session AES associée. Ceci empêche des pairs de distinguer\nles messages faisant partie de la même session, sachant que chaque message a une nouvelle étiquette complètement aléatoire. Pour accomplir ceci, tous les quelques messages empaquette un tout\nnouvel ensemble d’étiquettes de session dans le message chiffré lui-même, livrant d’une manière transparente\nune façon d’identifier des messages futurs. Nous devons alors garder la trace\nde quels messages sont livrés avec succès afin que nous sachions quelles étiquettes\nnous pouvons utiliser."
msgstr "Ceci marche bien et c’est assez robuste, cependant c’est inefficace en termes\nd’utilisation de bande passante, comme cela exige la livraison de ces étiquettes en avance de\ntemps (et toutes les étiquettes peuvent ne pas être nécessaires, ou certaines peuvent être gaspillés, en raison de\nleur expiration). En moyenne cependant, pré délivrer l’étiquette de session coûte\n32 octets par message (la taille d’une étiquette). Comme Taral l’a suggéré, cette\ntaille peut être évitée en remplaçant la livraison des étiquettes par un PRNG synchronisé\n - quand une nouvelle session est établie (via un block ElGamal chiffré),\nles deux côtés essaiment un PRNG pour utilisation et produisent les étiquettes de session sur\ndemande (avec le destinataire pré calculant à l’avance les quelques peu de valeurs suivantes possibles\nafin de traiter la panne de livraison)."
msgstr "La durée actuelle de tunnel est par défaut de 10 minutes, c’est assez arbitraire, quoique\ncela \"va bien\". Une fois que nous aurons le code de guérison de tunnel et un code de détection d’échec plus efficace, nous pourrons sans risque varier ces durées, réduisant les\ncharges réseau et UC (dues aux coûteux messages de création de tunnel)."
"Also, it would be difficult to maintain backward compatibility with such a change."
msgstr "Ceci semble être une réparation facile pour une haute charge sur des routeurs à grande bande passante, mais\nnous ne devrions pas y recourir jusqu’à ce que nous ayons ajusté le tunnel construisant des algorithmes plus loin. \nCependant, la durée de vie de tunnel de 10 minutes est codée en dur dans un bon nombre d’endroits,\ndonc un effort substantiel serait exigé pour changer la durée.\nAussi, il serait difficile de maintenir la compatibilité descendante avec un tel changement."
msgstr "Actuellement, puisque dans le réseau le taux de réussite de construction de tunnel est en moyenne assez élevé,\nil n’y a actuellement aucun plan visant à étendre la durée de vie de tunnel."
msgstr "Les temporisations actuelles pour diverses activités sont une autre des choses assez arbitraires, mais qui « semblent correcte » que nous avons. Pourquoi avons-nous une temporisation « pair inaccessible » de 60 secondes ? Pourquoi essayons-nous après 10 secondes d’envoyer au travers d’un tunnel différent que celui annoncé par le jeu de baux ? Pourquoi les requêtes à la base de données de réseau sont-elles restreintes par des limites de 60 ou 20 secondes ? Pourquoi les destinations sont-elles configurées pour demander un nouveau jeu de tunnels toutes les 10 minutes ? Pourquoi permettons-nous 60 secondes à un pair pour répondre à notre demande de se joindre à un tunnel ? Pourquoi considérons-nous comme « mort » un tunnel qui ne réussi pas notre test dans les 60 secondes ?"
msgstr "Chacun de ces impondérables peut être abordé avec du code plus adaptatif, et aussi\navec des paramètres ajustables pour tenir compte de différences plus appropriées entre\nbande passante, latence et utilisation de CPU."
msgstr "Limitation de bande passante au niveau du client (ou dans les deux directions sur un flux stream,\nou probablement partagée à travers de multiples flux stream). Ceci serait bien sûr en supplément à\nla limitation de bande passante globale du routeur."
msgstr "Des idées supplémentaires pour améliorer la bibliothèque de streaming sont décrites sur la\n<a href=\"%(streaming)s#future\">page de bibliothèque streaming</a>."
msgstr "Des améliorations notables de performance ont été faites en utilisant les techniques ci-dessous.\nIl y a plus à faire, voir la page <a href=\"%(performance)s\">performance</a>\npour les problèmes actuels et les idées."
"<a href=\"%(jbigi)s\">NativeBigInteger for faster public key cryptography</a></i>)"
msgstr "Quand j’ai dernièrement établi le profil du code d’I2P, la grande majorité du temps a été passée dans\nune fonction : java.math.BigInteger’s\n<a href=\"%(modpow)s\">modPow</a>.\nPlutôt que d’essayer d’accorder cette méthode, nous ferons appel à\n<a href=\"%(gmp)s\">GNU MP</a> - une bibliothèque mathématique follement rapide\n(avec assembleur accordé pour beaucoup d’architectures). (<i>éditeur : voir\n<a href=\"%(jbigi)s\">NativeBigInteger pour cryptographie clé publique plus rapide</a></i>)"
msgstr "\nugha et duck travaillent sur le code glue de C/JNI, et le code Java existant\nest déjà déployé avec des crochets pour cela quand ce sera prêt. Les résultats préliminaires\nsemblent fantastiques - faire tourner le routeur avec le modPow GMP natal fournit\nune accélération de 800* *37; de la performance en chiffrement, et la charge a été réduite à moitié. Ceci\nétait juste sur la machine d’un utilisateur et les choses sont très loin d’être prêtes pour le paquetage\nni le déploiement, pour le moment."
msgstr "Cet ajustement de l’algorithme ne sera seulement pertinent que pour les applications qui veulent que leurs pairs leur répondent (quoique cela inclue tout ce qui utilise I2PTunnel ou la bibliothèque «ministreaming» de mihi):"
msgstr "Précédemment, quand Alice a envoyé un message à Bob, quand Bob a répondu qu’il avait dû consulter la base de données de réseau, émettant quelques requêtes pour obtenir le jeu de baux actuel d’Alice. S’il a déjà le jeu de baux actuel d’Alice, il peut alors juste envoyer sa réponse immédiatement - c’est (en partie) pourquoi cela prend habituellement un peu plus longtemps de parler à quelqu’un la première fois que vous vous connectez, mais les communications subséquentes sont plus rapides. Actuellement, pour tous les clients, nous enveloppons le jeu de baux actuel de l’expéditeur dans l’ail qui est livré au destinataire, afin que lorsqu’ils s’apprêtent à répondre, ils aient <i>toujours</i> le jeu de baux stocké localement, supprimant complètement le besoin de consulter la base de données de réseau lors des réponses. \nCeci échange une grande partie de la bande passante de l’expéditeur contre cette réponse plus rapide.\nSi nous ne le faisions pas très souvent, l’utilisation globale de la bande passante du réseau diminuerait, puisque le destinataire n’a pas à consulter de base de données de réseau."
msgstr "Pour les jeux de baux non publiés tels que les « clients partagés », c’est la seule façon d’envoyer le jeu de baux à Bob. Malheureusement, ce groupage, répété toutes les fois, ajoute presque 100 % de surcharge à une connexion à large bande passante et beaucoup plus à une connexion avec de plus petits messages."
msgstr "Les changements prévus pour la version 0.6.2 grouperont le jeu de baux seulement si requis, au début d’une connexion ou quand le jeu de baux change.\nCela réduira considérablement la surcharge totale de la messagerie d’I2P."
msgstr "À l’heure actuelle, toutes les connexions TCP font toute leur validation de pair après\navoir passé la (coûteuse) poignée de mains Diffie-Hellman pour négocier une\nclé de session privée. Cela signifie que si l’horloge de quelqu’un est vraiment fausse, ou \nque leur NAT/pare-feu/etc est incorrectement configuré (ou qu’ils font juste fonctionner\nune version incompatible du routeur), ils vont systématiquement (quoique non\nconstamment, grâce à la banlist) causer un chère et futile opération cryptographique\nsur tous les pairs qu’ils connaissent. Tandis que nous voudrons garder quelques \nvérifications/validations dans la frontière de chiffrement, nous voudrons mettre à jour le\nprotocole pour faire un peu de cela d’abord, afin que nous puissions les rejeter proprement\nsans gaspiller beaucoup de CPU ou d’autres ressources."
msgstr "Plutôt qu’aller avec le plan assez aléatoire que nous avons maintenant, nous devrions utiliser un\nalgorithme plus conscient du contexte pour tester des tunnels. Par exemple si nous savons déjà qu’il\npasse des données valables correctement, il n’y a aucun besoin de le tester, tandis que si nous n’avons pas\nvu aucune données passer à travers récemment, peut-être qu’il est digne d’intérêt de jeter quelques données vers\nson chemin. Ceci réduira le conflit de tunnel en raison de l’excès de messages aussi bien qu’améliorer\nla vitesse à laquelle nous détectons - et adressons - les tunnels en échec."
msgstr "Sélectionner au hasard des tunnels et des baux pour chaque message crée une grande\nincidence de défaillance de livraison, laquelle empêche la lib streaming d'\naugmenter sa taille de fenêtre autant qu’elle le pourrait. En persistant avec les\nmêmes sélections pour une connexion donné, le taux de transfert est beaucoup plus rapide."
msgstr "Les messages I2NP et les données qu’ils contiennent sont déjà définis dans une structure assez compacte, bien qu’un attribut de la structure d’infosRouteur ne l’est pas. « options » est un mappage nom = valeur ASCII en clair. Pour l’instant, nous le remplissons avec ces statistiques publiées - autour de 3300 octets par pair. Facile à mettre en œuvre, la compression GZIP le réduirait presque d’un tiers et, quand l’on tient compte du nombre de fois que des structures InfosRouteur sont échangées par le réseau, cela représente des économies significatives. Chaque fois qu’un routeur demande à un autre routeur une entrée networkDb que le pair n’a pas, il en renvoie de 3 à 10 InfosRouteur."
"Currently mihi's ministreaming library has a fairly simple stream negotiation\n"
"protocol - Alice sends Bob a SYN message, Bob replies with an ACK message, then\n"
"Alice and Bob send each other some data, until one of them sends the other a\n"
"CLOSE message. For long lasting connections (to an IRC server, for instance),\n"
"that overhead is negligible, but for simple one-off request/response situations\n"
"(an HTTP request/reply, for instance), that's more than twice as many messages as\n"
"necessary. If, however, Alice piggybacked her first payload in with the SYN\n"
"message, and Bob piggybacked his first reply with the ACK - and perhaps also\n"
"included the CLOSE flag - transient streams such as HTTP requests could be\n"
"reduced to a pair of messages, instead of the SYN+ACK+request+response+CLOSE."
msgstr "Actuellement, la bibliothèque de minidiffusion de mihi a un protocole de négociation de flux assez simple. Alice envoie à Bob un message SYN, Bob répond par un message ACK, ensuite Alice et Bob s’envoient des données, jusqu’à ce que l’un d’entre eux envoie à l’autre un message CLOSE. Pour les connexions longues (p. ex. à un serveur IRC), cette surcharge est négligeable, mais pour les situations simples de demande/réponse unique (p. ex. une demande/réponse HTTP), c’est plus du double de messages que nécessaire. Si, cependant, Alice avait ajouté ses premières données utiles au message SYN et Bob avait ajouté sa première réponse avec le message ACK, et peut-être aussi\ninclus le drapeau CLOSE, les flux transitoires tels que les requêtes HTTP pourraient être réduits à deux messages, au lieu du SYN+ACK+requête+réponse+CLOSE."
msgstr "Le protocole « ministreaming » profite d’une mauvaise décision de conception dans le protocole client I2P (I2CP) ; l’exposition de « mode=GUARANTEED », permettant à ce qui serait autrement un protocole non fiable, au meilleur effort, basé sur des messages d’être utilisé pour une opération de blocage fiable (sous le capot, tout est encore non fiable et basé sur des messages, le routeur fournissant des garanties de livraison par l’enveloppage ail d’un message « ACK » avec les données utiles. Donc une fois que les données atteignent la cible, le message ACK nous est retourné [par des tunnels, bien sûr])."
msgstr "Comme je l’ai <a href=\"%(link)s\">dit</a>, avoir\nI2PTunnel (et la bibliothèque ministreaming) suivent cette route qui était la meilleure chose qui\npouvait être faite, mais des mécanismes plus efficaces sont disponibles. Quand nous retirons la\nfonctionnalité \"Mode=GUARANTEED\" , nous nous laissons essentiellement avec un\nI2CP qui ressemble à une couche IP anonyme, et comme telle, nous serons capables de\nmettre en œuvre la bibliothèque streaming pour profiter des expériences de conception\nde la couche TCP - ACKs sélectifs, détection de congestion, nagle, etc."
msgstr "Probablement qu’une de choses la plus fréquemment demandée par les gens est \"à quelle vitesse est I2P ?\",\net aucun ne semble aimer la réponse - \"cela dépend\". Après avoir essayé I2P, la\nchose suivante qu’ils demandent est \"deviendra-t-il plus rapide ?\", et la réponse à cela est plus\nemphatique <b>oui</b>."
"I2P is a full dynamic network. Each client is known to other nodes and tests local known nodes for reachability and capacity.\n"
"Only reachable and capable nodes are saved to a local NetDB (This is generally only a portion of the network, around 500-1000).\n"
"When I2P builds tunnels, it selects the best resource from this pool. For example, a small subset of 20-50 nodes are only available to build tunnels with.\n"
"Because testing happens every minute, the pool of used nodes changes every minute.\n"
"Each I2P node knows a different part of the net, meaning that each router has a different set of I2P nodes to be used for tunnels.\n"
"Even if two routers have the same subset of known nodes, the tests for reachability and capacity will likely show different results, as the other routers could be under load just as one router tests, but be free if the second router tests."
msgstr "I2P est un réseau complètement dynamique. Chaque client est connu par les autres nœuds et teste l’accessibilité et la capacité des nœuds locaux connus.\nSeuls les nœuds accessibles et aptes sont enregistrés dans une base de données NetDB locale (généralement une portion du réseau seulement, environ 500 à 1 000).\nQuand I2P construit des tunnels, la meilleure ressource est sélectionnée de cette réserve. Par exemple, un petit sous-ensemble de 20 à 50 nœuds n’est disponible que pour construire des tunnels.\nAvec des tests toutes les minutes, la réserve de nœuds utilisés change toutes les minutes.\nChaque nœud d’I2P connaît une partie différente du réseau, ce qui signifie que chaque routeur connaît un ensemble différent de nœuds d’I2P pouvant être utilisés pour les tunnels.\nMême si deux routeurs possédaient le même sous-ensemble de nœuds connus, les tests d’accessibilité et de capacité donneraient probablement des résultats différents, car les autres routeurs pourraient subir une charge lors du test d’un routeur, mais être libres lors du test du deuxième routeur."
"The above describes why each I2P node has different nodes to build tunnels.\n"
"Because every I2P node has a different latency and bandwith, tunnels (which are built via those nodes) have different latency and bandwidth values.\n"
"And because every I2P node has different tunnels built, no two I2P nodes have the same tunnel sets."
msgstr "Le texte ci-dessus décrit pourquoi chaque noeud I2P a des noeuds différents pour construire des tunnels.\nParce que chaque noeud I2P a une latence différente et une largeur de bande passante, des tunnels (qui sont construits via ces noeuds) ont une latence différente et des valeurs différentes de bande passante.\nEt parce que chaque noeud I2P a différents tunnels construits, aucun de deux noeud I2P n’a les mêmes ensembles de tunnels."
"A server/client is known as a \"destination\" and each destination has at least one inbound and one outbound tunnel. The default is 3 hops per tunnel.\n"
"This adds up to 12 hops (aka 12 different I2P nodes) for a full roundtrip client-server-client."
msgstr "Un serveur ou client est connu comme une « destination » et chaque destination a au moins un tunnel entrant et un tunnel sortant. Il y a par défaut 3 sauts par tunnel.\nCela s’élève à 12 sauts (c.-à-d. 12 nœuds I2P différents) pour un aller-retour complet client-serveur-client."
"As the RTT (RoundTripTime) adds up from the latency of each individual I2P node and each connection on this roundtrip, it takes usually 1-3 seconds until a ack package comes back to the client.\n"
"With some internals of TCP and I2P transport, a data package has a limited size and cannot be as large as we want it to be.\n"
"Together these conditions set a limit of max bandwidth per tunnel of 20-50 kbyte/sec.\n"
"But if ONLY ONE hop in the tunnel has only 5 kb/sec bandwidth to spend, the whole tunnel is limited to 5 kb/sec, independent of the \n"
msgstr "Comme la plupart du trafic sur I2P (www, torrent, ...) a besoin de paquets ack jusqu’à ce que de nouvelles données soient envoyées, il doit attendre jusqu’à ce qu’un paquet ack revienne du serveur.\nAu final : envoyer des données, attendre ack, envoyer plus de données, attendre ack, ...\nComme le RTT (RoundTripTime) s’additionne de la latence de chaque noeud individuel I2P et chaque connexion de cet aller-retour, cela prend d’habitude 1-3 secondes jusqu’à ce qu’un paquet ack revienne au client.\nAvec quelques composants de TCP et du transport d’I2P, un paquet de données a une taille limitée et ne peut pas être aussi grand que nous le voudrions.\nEnsemble, ces conditions mettent une limite de bande passante maximum par tunnel de 20-50 Ko/sec.\nMais si SEULEMENT UNE étape dans le tunnel a une bande passante de seulement 5 Ko/sec à dépenser, le tunnel entier est limité à 5 Ko/sec, indépendamment de la\nlatence et d’autres limitations."
"Due to encryption used and other setups in I2P (howto built up tunnels, latency, ...) it is quite expensive in CPU time to build a tunnel. This is \n"
"why a destination is only allowed to have a max of 6 IN and 6 OUT tunnels to transport data. With a max of 50 kb/sec per tunnel, a destination could \n"
"use roughly 300 kb/sec traffic combined ( in reality it could be more if shorter tunnels are used with low or no anonymity available).\n"
"This change of tunnels (and sometimes clients that shutdown hard due to usage of \"shut down at once\" or situations where there is power loss) does \n"
"sometimes break tunnels and connections, as seen on the IRC2P Network in loss of connection (ping timeout) or on when using eepget."
msgstr "En raison du chiffrement utilisé et d’autres configurations dans I2P (comment construire des tunnels, la latence...) la construction d’un tunnel est gourmande en temps UCT. C’est pourquoi une destination n’est autorisée à avoir qu’un maximum de 6 tunnels entrants et 6 sortants pour transporter les données. Avec un maximum de 50 kb/s par tunnel, une destination pourrait utiliser à peu près 300 kb/s de trafic combiné (en réalité peut-être plus si des tunnels plus courts sont utilisés avec un anonymat disponible faible ou nul).\nLes tunnels utilisés sont éliminés toutes les 10 minutes et d’autres sont construits.\nCe changement de tunnels (et parfois des clients qui se ferment à froid, car ils utilisent la « fermeture immédiate » ou des situations de panne de courant) met parfois fin aux tunnels et aux connexions, comme observé sur le réseau IRC2P en perte de connexion (dépassement du temps de ping) ou lors de l’utilisation d’eepget."
"With a limited set of destinations and a limited set of tunnels per destination, one I2P node only uses a limited set of tunnels across other I2P nodes.\n"
"For example, if an I2P node is \"hop1\" in the small example above, we only see 1 participating tunnel originating from the client.\n"
"If we sum up the whole I2P network, only a rather limited number of participating tunnels could be built with a limited amount of bandwidth all together.\n"
"If one distributes these limited numbers across the number of I2P nodes, there is only a fraction of available bandwidth/capacity available for use."
msgstr "Avec un ensemble limité de destinations et un ensemble limité de tunnels par destination, un noeud I2P utilise seulement un ensemble limité de tunnels à travers d’autres noeuds I2P.\nPar exemple, si un noeud I2P est \"hop1\" dans le petit exemple ci-dessus, nous voyons seulement 1 tunnel participant provenant du client.\nSi nous résumons le réseau I2P entier, seul un nombre plutôt limité de tunnels participants pourrait être construit avec une quantité limitée de bande passante tous ensemble.\nSi on distribue ces nombres limités à travers le numéro de noeuds I2P, il y a seulement une fraction de bande passante/capacité disponible disponible pour utilisation."
"To remain anonymous one router should not be used by the whole network for building tunnels.\n"
"If one router does act as a tunnel router for ALL I2P nodes, it becomes a very real central point of failure as well as a central point to grab IPs and data from the clients. This is not good.\n"
"I2P attempts to spread the load across a lot of I2P nodes because of this reason."
msgstr "Pour rester anonyme, un routeur ne devrait pas être utilisé par l’ensemble du réseau pour la construction de tunnels.\nSi un routeur agit comme routeur de tunnels pour tous les nœuds d’I2P, il devient un véritable point central de défaillance, ainsi qu’un point central pour récolter des adresses IP et des données des clients. Ce n’est pas souhaitable.\nI2P tente de répartir la charge sur un grand nombre de nœuds d’I2P pour cette raison."
"Another point is the full mesh network. Each connection hop-hop utilizes one TCP or UDP connection on the I2P nodes. With 1000 connections, one sees \n"
"1000 TCP connections. That is quite a lot and some home and small office routers (DSL, cable,..) only allow a small number of connections (or just go mad if you use more than X connections).\n"
"I2P tries to limit these connections to be under 1500 per UDP and per TCP type.\n"
msgstr "Un autre point est le réseau complètement maillé. Chaque connexion saut-à-saut utilise une connexion TCP ou UDP sur les nœuds I2P. Avec 1000 connexions, on voit\n1000 connexions TCP. C’est beaucoup et certains routeurs (DSL, câble, ...) domestique ou de petit bureau permettent seulement un petit nombre de connexions (ou deviennent simplement fous si vous utilisez plus de X connexions.)\nI2P essaie de limiter le nombre de ces connexions pour être en dessous de 1500 par UDP et par type TCP.\nCe qui limite la quantité de trafic acheminé à travers votre nœud I2P aussi."
"In summary, I2P is very complex and there is no easy way to pinpoint why your node is not used.\n"
"If your node is reachable and has a bandwidth setting of >128 kbyte/sec shared and is reachable 24/7, it should be used after some time for participating traffic.\n"
"If it is down in between, the testing of your I2P node done by other nodes will tell them: you are not reachable. This blocks your node for at least \n"
"24h on other nodes. So, the other nodes which tested you as down will not use your node for 24h for building tunnels. This is why your traffic will \n"
msgstr "En résumé, I2P est très complexe et il n’y a aucune façon facile d’identifier exactement pourquoi votre nœud n’est pas utilisé.\nSi votre nœud est accessible, a un paramètre de bande passante partagée > à 128 ko/s, est accessible jour et nuit, il devrait être utilisé après quelque temps pour le trafic participant. \nS’il est hors service entre temps, le test de votre nœud I2P par d’autres nœuds leur indiquera que vous n’êtes pas accessible. Pour les autres nœuds, votre nœud sera bloqué pour au moins 24 h. Ainsi, les autres nœuds qui vous ont testé comme étant hors service n’utiliseront pas votre nœud pour construire des tunnels durant 24 h. C’est pourquoi votre trafic sera inférieur après un redémarrage, une fermeture pendant au moins 24 h."
"Also: other I2P nodes needs to know your I2P router to test it for reachability and capacity. It takes time for other nodes to get known to your node. \n"
"It will be faster if you use I2P and build more tunnels, e.g. use a torrent or www for some time."
msgstr "Aussi : les autres noeuds I2P doivent connaître votre routeurI2P pour tester son accessibilité et sa capacité. Cela prend du temps pour que les autres noeuds prennent connaissance de votre noeud.\nCela sera plus rapide si vous utilisez I2P et construisez davantage de tunnels, par exemple utilisez un torrent ou www pendant quelque temps."
