Vous trouverez ci-dessous une exposition plus détaillée (bien que toujours incomplète) des principales zones du développement du cœur du réseau I2P, embrassant les nouvelles versions éventuellement planifiées. Ceci n'inclu ni le transport stéganographique, @@ -17,113 +17,102 @@ Traduction en cours (24 fév 2011)
The functionality of allowing routers to fully participate within the network - while behind firewalls and NATs that they do not control requires some basic - restricted route operation (since those peers will not be able to receive - inbound connections). To do this successfully, you consider peers one of - two ways:
+ Implémenté dans I2P 0.6.0.6 +La fonctionalité permettant aux routeurs de participer pleinement aux réseau + même lorsqu'ils se trouvent derrière un pare-feu ou un traducteur d'adresses réseau (NAT) hors de contrôle nécessite quelques + opérations avec une route réservée (car ces pairs ne peuvent pas recevoir + de connexions entrantes). Pour y parvenir, il y a deux façons de considérer les pairs:
To do this, peers who have no IP address simply connect to a few peers, - build a tunnel through them, and publish a reference to those tunnels within - their RouterInfo structure in the network database.
-When someone wants to contact any particular router, they first must get - its RouterInfo from the network database, which will tell them whether they - can connect directly (e.g. the peer has a publicly reachable interface) - or whether they need to contact them indirectly. Direct connections occur - as normal, while indirect connections are done through one of the the published - tunnels.
-When a router just wants to get a message or two to a specific hidden peer, - they can just use the indirect tunnel for sending the payload. However, - if the router wants to talk to the hidden peer often (for instance, as part - of a tunnel), they will send a garlic routed message through the indirect - tunnel to that hidden peer which unwraps to contain a message which should - be sent to the originating router. That hidden peer then establishes an - outbound connection to the originating router and from then on, those two - routers can talk to each other directly over that newly established direct - connection.
-Of course, that only works if the originating peer can receive connections - (they aren't also hidden). However, if the originating peer is hidden, they - can simply direct the garlic routed message to come back to the originating - peer's inbound tunnel.
-This is not meant to provide a way for a peer's IP address to be concealed, - merely as a way to let people behind firewalls and NATs fully operate within - the network. Concealing the peer's IP address adds a little more work, as - described below.
-With this technique, any router can participate as any part of a tunnel. - For efficiency purposes, a hidden peer would be a bad choice for an inbound - gateway, and within any given tunnel, two neighboring peers wouldn't want - to be hidden. But that is not technically necessary.
+Pour ce faire, les pairs privés se connectent simplement à quelques autres, + créent un tunnel à travers chacun d'eux, et en publient une référence dans leur + structure RouterInfo de la base de donnée du réseau.
+Lorsque quelqu'un souhaite joindre un routeur particulier, il doit d'abord obtenir + sa "RouterInfo" à partir de la base de donnée, et il saura s'il peut se connecter + directement (cas du pair cible public) ou indirectement. Les connexions directes se passent + normalement, alors que les indirectes se font via les tunnels publiés.
+Quand un routeur veut seulement envoyer un ou deux messages à un pair caché, + il peut simplement utiliser le tunnel indirect publié pour envoyer les données utiles. Cependant, + si le routeur doit converser souvent avec le pair privé (par exemple en tant que participant + à un tunnel), il doit envoyer un message "routé-à-la-garlic" à travers le tunnel + indirect au pair caché, qui le déballe pour y trouver... un message destiné au routeur originaire. + Le pair caché établit alors une connexion sortante + au routeur originaire et à partir de là ces deux + routeurs peuvent converser directement sur cette nouvelle connexion.
+Ce scénario ne peut bien sûr fonctionner que si le pair originaire peut recevoir des connexions + (c'est-à-dire qu'il ne soit pas lui-même caché). Cependant, s'il est caché lui aussi, il peut indiquer dans + le message initial de revenir par son propre tunnel d'entrée.
+Ceci n'est pas destiné à fournir aux pairs un moyen de dissimuler leur adresse IP, + mais plutôt pour permettre à ceux opérant derrière un pare-feu ou un NAT de participer normalement + au réseau. La dissimulation d'adresse IP demande plus de travail, comme + décrit plus bas.
+Avec cette méthode, n'importe quel routeur peut participer à tout rôle dans un tunnel. + Dans un but d'efficacité, opérer en pair caché est un mauvais choix pour officier en tant que passerelle d'entrée, + et dans un tunnel donné, deux pairs voisins ne devraient pas être cachés. Mais ça n'est pas indispensable.
Standard TCP communication in Java generally requires blocking socket - calls, and to keep a blocked socket from hanging the entire system, those - blocking calls are done on their own threads. Our current TCP transport - is implemented in a naive fashion - for each peer we are talking to, we - have one thread reading and one thread writing. The reader thread simply - loops a bunch of read() calls, building I2NP messages and adding them - to our internal inbound message queue, and the writer thread pulls messages - off a per-connection outbound message queue and shoves the data through - write() calls.
-We do this fairly efficiently, from a CPU perspective - at any time, - almost all of these threads are sitting idle, blocked waiting for something - to do. However, each thread consumes real resources (on older Linux kernels, - for instance, each thread would often be implemented as a fork()'ed process). - As the network grows, the number of peers each router will want to talk - with will increase (remember, I2P is fully connected, meaning that any - given peer should know how to get a message to any other peer, and restricted - route support will probably not significantly reduce the number of connections - necessary). This means that with a 100,000 router network, each router - will have up to 199,998 threads just to deal with the TCP connections!
-Obviously, that just won't work. We need to use a transport layer that - can scale. In Java, we have two main camps:
+La communication TCP standard dans Java nécessite habituellement des appels de socket + bloquants, et pour pour empêcher un socket de bloquer le bloquer tout le système, ces + appels sont faits dans leur propres tâches. Notre transport TCP actuel + est implémenté de façon naïve - pour chaque pair en relation, nous avons + une tâche de lecture et une tâche d'écriture. Celle de lecture boucle simplement sur + un paquet d'appels read(), construit les messages I2NP et les ajoute à notre file d'attente + interne entrante. Il y a une file d'attente de messages sortants par connexion. La tâche d'écriture en extrait les messages + et passe les données à travers les appels write().
+Nous effectuons ceci assez efficacement d'un point de vue charge UC - à tout moment, + presque toutes ces tâches sont au repos, bloquées dans l'attente de grain à moudre. + Cependant, chacune d'entre elles consomme des ressources réelles (par exemple sur de très vieux + noyaux Linux, chacune sera souvent mise en œuvre en tant que processus fork()'ed). + À mesure de la croissance du réseau, le nombre de pairs auxquels chaque routeur voudra s'adresser + augmentera (souvenez-vous, I2P est entièrement connecté, c'est-à-dire que chaque pair doit savoir + comment passer des messages à tous les autres. Le support des routes réservées + ne réduira probablement pas sensiblement le nombre de connexions + nécessaires). Ce qui veut dire que dans un réseau de 100000 routeurs, chaque routeur + aura jusqu'à 199998 tâches rien que pour s'occuper des connexions TCP!
+Évidement, ça ne marchera pas. Nous avons besoin d'une couche transport adaptative. + Dans Java, nous disposons de deux approches principales:
Sending and receiving UDP datagrams is a connectionless operation - if - we are communicating with 100,000 peers, we simply stick the UDP packets - in a queue and have a single thread pulling them off the queue and shoving - them out the pipe (and to receive, have a single thread pulling in any - UDP packets received and adding them to an inbound queue).
-However, moving to UDP means losing the benefits of TCP's ordering, congestion - control, MTU discovery, etc. Implementing that code will take significant - work, however I2P doesn't need it to be as strong as TCP. Specifically, - a while ago I was taking some measurements in the simulator and on the - live net, and the vast majority of messages transferred would fit easily - within a single unfragmented UDP packet, and the largest of the messages - would fit within 20-30 packets. As mule pointed out, TCP adds a significant - overhead when dealing with so many small packets, as the ACKs are within - an order of magnitude in size. With UDP, we can optimize the transport - for both efficiency and resilience by taking into account I2P's particular - needs.
-It will be a lot of work though.
+ Implémenté dans I2P 0.6 ("SSU") tel que documenté ailleurs. +L'envoi et la réception de datagrammes UDP sont des opérations sans connexion - si + on communique avec 100000 pairs, on colle simplement les paquets UDP dans une file + d'attente et on fait avec une seule tâche pour les extraire et les pousser dans le tuyau + (et pour recevoir, une seule tâche en tire les paquets UDP reçus et les ajoute dans une file d'entrée).
+L'ennui, c'est que l'utilisation de UDP fait perdre les avantages de TCP (réordonnancement, gestion de la congestion, + découverte du MTU, etc). Mettre ce code en œuvre demandera un travail important, + mais I2P n'a pas besoin d'être aussi solide que TCP. Précisément, + lorsque j'ai fait des mesures au simulateur et en réel sur Internet, + la plupart des messages transférés tenaient facilement dans un seul paquet UDP + non fragmenté, et les plus gros messages prenaient 20 à 30 paquets. + Comme mule le mit en évidence, TCP ajoute une surcharge certaine quand il s'agit de gérer + autant de petits paquets, vu que les ACKs sont du même ordre de grandeur. + Avec UDP, nous pouvons optimiser le transport tant pour l'efficacité que pour la souplesse + en prenant en compte les besoins spécifiques d'I2P.
+Ça ne va malgré tout pas être un énorme travail.
In Java 1.4, a set of "New I/O" packages was introduced, allowing Java