Ça ne va malgré tout pas être un énorme travail.
+Ça ne va quand-même pas être un travail énorme.
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 Kaffe, - as GNU/Classpath has only limited - support for NIO. (note: this may not be the case anymore, as there - has been some progress on Classpath's NIO, but it is an unknown quantity)
-Another alternative along the same lines is the Non - Blocking I/O 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).
+ NIO implémenté dans I2P 0.6.1.22 ("NTCP") +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 Kaffe, car + GNU/Classpath ne les supporte que partiellement. (note: ça ne devrait + pas durer car il y a eu quelques progrès dans les NIO de Classpath, bien qu'en quantité inconnue)
+Dans la même veine, il y a l'alternative du paquetage + Non blocking IO - + 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).
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.
-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.
+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.
+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.
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<--B<--C<--D<--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. + Depuis I2P v0.5 et documenté là. +
À 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<--B<--C<--D<--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 œuvre. +
+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é.
-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.
-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.
+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.
- Performance related improvements are listed on the - Performance page. + Les améliorations de performances sont répertoriées sur une page dédiée aux + performances.
{% endblock %}