From 9a4d62d921e2a2f77b7491b16d85c048dbed58b4 Mon Sep 17 00:00:00 2001
From: magma <magma@mail.i2p>
Date: Sat, 26 Feb 2011 14:50:37 +0000
Subject: [PATCH] udp todo_fr

---
 www.i2p2/pages/todo_fr.html | 144 +++++++++++++++++-------------------
 1 file changed, 66 insertions(+), 78 deletions(-)

diff --git a/www.i2p2/pages/todo_fr.html b/www.i2p2/pages/todo_fr.html
index 50a2d71f..3bf1ef19 100644
--- a/www.i2p2/pages/todo_fr.html
+++ b/www.i2p2/pages/todo_fr.html
@@ -112,92 +112,80 @@ Traduction en cours (25 f&eacute;v 2011)
         autant de petits paquets, vu que les ACKs sont du m&ecirc;me ordre de grandeur.
         Avec UDP, nous pouvons optimiser le transport tant pour l'efficacit&eacute; que pour la souplesse
         en prenant en compte les besoins sp&eacute;cifiques d'I2P.</p>
-      <p>&Ccedil;a ne va malgr&eacute; tout pas &ecirc;tre un &eacute;norme travail.</p>
+      <p>&Ccedil;a ne va quand-m&ecirc;me pas &ecirc;tre un travail &eacute;norme.</p>
       <h4>NIO or NBIO</h4>
-      <b><i>NIO Implemented in I2P 0.6.1.22 ("NTCP")</i></b> 
-      <p>In Java 1.4, a set of "New I/O" packages was introduced, allowing Java 
-        developers to take advantage of the operating system's nonblocking IO 
-        capabilities - allowing you to maintain a large number of concurrent IO 
-        operations without requiring a separate thread for each. There is much 
-        promise with this approach, as we can scalable handle a large number of 
-        concurrent connections and we don't have to write a mini-TCP stack with 
-        UDP. However, the NIO packages have not proven themselves to be battle-ready, 
-        as the Freenet developer's found. In addition, requiring NIO support would 
-        mean we can't run on any of the open source JVMs like <a href="http://www.kaffe.org/">Kaffe</a>, 
-        as <a href="http://www.classpath.org/">GNU/Classpath</a> has only limited 
-        support for NIO. <i>(note: this may not be the case anymore, as there 
-        has been some progress on Classpath's NIO, but it is an unknown quantity)</i></p>
-      <p>Another alternative along the same lines is the <a href="http://www.eecs.harvard.edu/~mdw/proj/java-nbio/">Non 
-        Blocking I/O</a> package - essentially a cleanroom NIO implementation 
-        (written before NIO was around). It works by using some native OS code 
-        to do the nonblocking IO, passing off events through Java. It seems to 
-        be working with Kaffe, though there doesn't seem to be much development 
-        activity on it lately (likely due to 1.4's NIO deployment).</p>
+      <b><i>NIO implémenté dans I2P 0.6.1.22 ("NTCP")</i></b> 
+      <p>Java 1.4 propose un jeu de paquetage "New I/O", permettant aux  
+        développeurs de tirer avantage des possibilités d'E/S non blocantes du système d'exploitation 
+        - vous pouvez maintenir un grand nombre d'opérations d'E/S simultanées sans avoir besoin de définir une tâche 
+        dédiée pour chacune. Cette approche est très prometteuse, car nous pouvons utiliser un grand nombre de connexion 
+        simultanées et nous n'avons pas besoin d'écrire une mini-pile TCP pour UDP. Cependant, selon les développeurs
+        de Freenet les paquetages NIO n'ont passé l'épreuve du feu. De plus, le recours aux NIO impliquerait une 
+        incompatibilité avec les JVM open-sources telles que <a href="http://www.kaffe.org/">Kaffe</a>, car 
+        <a href="http://www.classpath.org/">GNU/Classpath</a> ne les supporte que partiellement. <i>(note: ça ne devrait 
+        pas durer car il y a eu quelques progrès dans les NIO de Classpath, bien qu'en quantité inconnue)</i></p>
+      <p>Dans la même veine, il y a l'alternative du paquetage 
+        <a href="http://www.eecs.harvard.edu/~mdw/proj/java-nbio/">Non blocking IO</a> - 
+        essentiellement une implémentation NIO de salle blanche (écrite avant la parution des NIO). 
+        Il utilise du code natif du SE pour faire les E/S non blocantes, en présentant les évènements via Java. 
+        Il semble fonctionner avec Kaffe, mais il a peu d'activité de développement à son sujet (probablement 
+        à cause de la parution des NIO de Java 1.4).</p>
     </li>
   </ul>
   <ul class="targetlist">
     <li> 
-      <h3 id="netdb">NetworkDB and profile tuning and ejection policy for large 
-        nets</h3>
-      <p>Within the current network database and profile management implementation, 
-        we have taken the liberty of some practical shortcuts. For instance, we 
-        don't have the code to drop peer references from the K-buckets, as we 
-        don't have enough peers to even plausibly fill any of them, so instead, 
-        we just keep the peers in whatever bucket is appropriate. Another example 
-        deals with the peer profiles - the memory required to maintain each peer's 
-        profile is small enough that we can keep thousands of full blown profiles 
-        in memory without problems. While we have the capacity to use trimmed 
-        down profiles (which we can maintain 100s of thousands in memory), we 
-        don't have any code to deal with moving a profile from a "minimal profile" 
-        to a "full profile", a "full profile" to a "minimal profile", or to simply 
-        eject a profile altogether. It just wouldn't be practical to write that 
-        code yet, since we aren't going to need it for a while.</p>
-      <p>That said, as the network grows we are going to want to keep these considerations 
-        in mind. We will have some work to do, but we can put it off for later.</p>
+      <h3 id="netdb">Base de donn&eacute;e r&eacute;seau, ajustement de profil et strat&eacute;gie d'&eacute;jection pour les grands r&eacute;seaux.</h3>
+      <p>Dans l'implémentation actuelle de la base de donnée réseau et de la gestion de profil, 
+        on s'est permi quelques raccourcis pratiques. Par exemple, nous n'avons pas de code pour 
+        nettoyer les références aux pairs dans les K-buckets, vu que nous n'avons pas assez de pairs pour avoir ne 
+        serait-ce qu'une petite chance d'en remplir une. Alors on garde les pairs dans n'importe quelle liste appropriée. 
+        Un autre exemple avec les profils de pairs: la quantité de mémoire nécessaire pour maintenir chaque profil est suffisament 
+        faible pour que nous puissions garder des milliers de profils bien détaillés sans aucun problème. 
+        Comme nous avons la possibilité d'utiliser des profils réduits (dont nous pouvons maintenir des centaines de 
+        milliers en mémoire), nous n'avons pas non-plus le code qui ferait la conversion de détaillé en réduit et vice-versa,
+        ni même la purge des deux. Ça ne serait pertinent d'écrire ce code maintenant car nous sommes loin d'en avoir besoin 
+        avant longtemps.</p>
+      <p>Ceci dit, nous devons quand même garder ça en tête car la taille du réseau grandit. 
+         Il restera du travail, mais on peut le remettre à plus tard.</p>
     </li>
   </ul>
-  <h2 id="security">Security / anonymity</h2>
+  <h2 id="security">Sécurité / anonymat</h2>
   <ul class="targetlist">
     <li> 
-      <h3 id="tunnelId">Per-hop tunnel id &amp; new permuted TunnelVerificationStructure 
+      <h3 id="tunnelId">ID de tunnel "par saut" &amp; nouvelle encryption permut&eacute;e de la structure de v&eacute;rification des tunnels. TunnelVerificationStructure 
         encryption</h3>
-      <b><i>Addressed in I2P 0.5 as documented <a href="tunnel-alt.html">elsewhere</a></i></b> 
-      <p>Right now, if Alice builds a four hop inbound tunnel starting at Elvis, 
-        going to Dave, then to Charlie, then Bob, and finally Alice (A&lt;--B&lt;--C&lt;--D&lt;--E), 
-        all five of them will know they are participating in tunnel "123", as 
-        the messages are tagged as such. What we want to do is give each hop their 
-        own unique tunnel hop ID - Charlie will receive messages on tunnel 234 
-        and forward them to tunnel 876 on Bob. The intent is to prevent Bob or 
-        Charlie from knowing that they are in Alice's tunnel, as if each hop in 
-        the tunnel had the same tunnel ID, collusion attacks aren't much work. 
+      <b><i>Depuis I2P v0.5 et documenté <a href="tunnel-alt.html">là</a>.</i></b> 
+      <p>À l'heure actuelle, quand Alice initie un tunnel entrant à quatre sauts commençant par Elvis, 
+        puis passant par Dave, puis Charlie,puis Bob, et se terminant chez elle, Alice (A&lt;--B&lt;--C&lt;--D&lt;--E), 
+        tous les cinq sont au fait qu'ils participent au tunnel "123", car 
+        les messages font en font état (TunnelID commun). Nous voulons donner à chaque saut un 
+        identifiant unique de saut de tunnel:Charlie recevra des messages sur le tunnel 234 
+        et les transmettra à Bob par le tunnel 876. Le but est d'empêcher Bob ou 
+        Charlie de savoir qu'ils participent au tunnel d'Alice, car quand chaque saut 
+        a le même tunnelID pour un tunnel donné, les attaques par coalition sont simples à mettre en &oelig;uvre. 
+      </p> 
+      <p>L'ajout d'un TunnelID unique par saut n'est pas difficile, mais c'est insuffisant: 
+        Si Dave et Bob sont contrôlés par le même attaquant, ils ne pourraient plus identifier un tunnel 
+        par leur participation commune via l'information TunnelID, mais seraient quand-même capable de le  
+        faire par simple comparaison des corps de messages et des structures de vérification.
+        Pour l'empêcher, le tunnel doit appliquer un cryptage étagé tout au long du chemin, 
+        à la fois sur la charge utile et les structures de vérification (utilisées pour empêcher les attaques 
+        par marquages). On a besoin de modifications simples du TunnelMessage, et aussi d'inclure par saut, des clés
+        secrètes générées pendant la création du tunnel et passées à la passerelle du tunnel.
+        Nous devons définir une longueur maximale de tunnel (p.e. 16 sauts) 
+        et indiquer à la passerelle de chiffrer le message pour chacune des 16 clés, 
+        en ordre inverse, et de crypter la signature du hachage de la charge utile (cryptée) à chaque étape. 
+        La passerelle envoie alors ce message au premier saut chiffré 16 fois, accompagné d'un plan 
+        à 16 entrée chiffré 16 fois. Le premier saut déchiffre le plan et la charge utile avec leur clef secrète 
+        pour chercher dans le plan l'entrée associée à son propre saut (indiquée par le tunnelID unique par saut) 
+        et pour vérifier la charge utile en la confrontant au hachage signé associé.
       </p>
-      <p>Adding a unique tunnel ID per hop isn't hard, but by itself, insufficient. 
-        If Dave and Bob are under the control of the same attacker, they wouldn't 
-        be able to tell they are in the same tunnel due to the tunnel ID, but 
-        would be able to tell by the message bodies and verification structures 
-        by simply comparing them. To prevent that, the tunnel must use layered 
-        encryption along the path, both on the payload of the tunneled message 
-        and on the verification structure (used to prevent simple tagging attacks). 
-        This requires some simple modifications to the TunnelMessage, as well 
-        as the inclusion of per-hop secret keys delivered during tunnel creation 
-        and given to the tunnel's gateway. We must fix a maximum tunnel length 
-        (e.g. 16 hops) and instruct the gateway to encrypt the message to each 
-        of the 16 delivered secret keys, in reverse order, and to encrypt the 
-        signature of the hash of the (encrypted) payload at each step. The gateway 
-        then sends that 16-step encrypted message, along with a 16-step and 16-wide 
-        encrypted mapping to the first hop, which then decrypts the mapping and 
-        the payload with their secret key, looking in the 16-wide mapping for 
-        the entry associated with their own hop (keyed by the per-hop tunnel ID) 
-        and verifying the payload by checking it against the associated signed 
-        hash.</p>
-      <p>The tunnel gateway does still have more information than the other peers 
-        in the tunnel, and compromising both the gateway and a tunnel participant 
-        would allow those peers to collude, exposing the fact that they are both 
-        in the same tunnel. In addition, neighboring peers know that they are 
-        in the same tunnel anyway, as they know who they send the message to (and 
-        with IP-based transports without restricted routes, they know who they 
-        got it from). However, the above two techniques significantly increase 
-        the cost of gaining meaningful samples when dealing with longer tunnels.</p>
+      <p>La passerelle dispose encore de plus d'informations que les autre pairs, 
+        et sa compromission avec un participant leur permettrait d'indentier leur participation à un tunnel donné.
+        De toute façon, les pairs voisins savent qu'ils participent au même tunnel, car ils savent à qui ils 
+        envoient un message (et avec les transport IP sans routes réservées, ils savent aussi de qui ils reçoivent). 
+        Malgré tout, les deux techniques ci-dessus augmentent très sensiblement le coût d'obtension d'échantillons 
+        signifiants dans des tunnels très longs.</p>
     </li>
     <ul class="targetlist">
       <li> 
@@ -322,9 +310,9 @@ Traduction en cours (25 f&eacute;v 2011)
         clove exposed includes delay instructions.</p>
     </li>
   </ul>
-  <h2 id="performance">Performance</h2>
+  <h2 id="performance">Performances</h2>
   <p>
-  Performance related improvements are listed on the
-  <a href="performance.html">Performance</a> page.
+  Les am&eacute;liorations de performances sont r&eacute;pertori&eacute;es sur une page d&eacute;di&eacute;e aux
+  <a href="performance.html">performances</a>.
   </p>
 {% endblock %}