Des améliorations notables de performance ont été faites en utilisant les techniques ci-dessous. Il y a plus à faire, voir la page performance pour les problèmes actuels et les idées.

Maths natives

Quand j’ai dernièrement établi le profil du code d’I2P, la grande majorité du temps a été passée dans une fonction : java.math.BigInteger’s modPow. Plutôt que d’essayer d’accorder cette méthode, nous ferons appel à GNU MP – une bibliothèque mathématique follement rapide (avec assembleur accordé pour beaucoup d’architectures). (éditeur : voir NativeBigInteger pour cryptographie clé publique plus rapide)

ugha et duck travaillent sur le code glue de C/JNI, et le code Java existant est déjà déployé avec des crochets pour cela quand ce sera prêt. Les résultats préliminaires semblent fantastiques - faire tourner le routeur avec le modPow GMP natal fournit une accélération de 800* *37; de la performance en chiffrement, et la charge a été réduite à moitié. Ceci était juste sur la machine d’un utilisateur et les choses sont très loin d’être prêtes pour le paquetage ni le déploiement, pour le moment.

Ail enveloppant un jeux de baux "réponse"

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) :

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 qu’ils aient toujours le jeu de baux stocké localement quand ils s’apprêtent à répondre, supprimant complètement le besoin de consulter la base de données de réseau lors des réponses. Ceci échange une grande partie de la bande passante de l’expéditeur contre cette réponse plus rapide. Si 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.

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.

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. Cela réduira considérablement la surcharge totale de la messagerie d’I2P.

Refus TCP plus efficace

À l’heure actuelle, toutes les connexions TCP font toute leur validation de pair après avoir passé la (coûteuse) poignée de mains Diffie-Hellman pour négocier une clé de session privée. Cela signifie que si l’horloge de quelqu’un est vraiment fausse, ou que leur NAT/pare-feu/etc est incorrectement configuré (ou qu’ils font juste fonctionner une version incompatible du routeur), ils vont systématiquement (quoique non constamment, grâce à la banlist) causer un chère et futile opération cryptographique sur tous les pairs qu’ils connaissent. Tandis que nous voudrons garder quelques vérifications/validations dans la frontière de chiffrement, nous voudrons mettre à jour le protocole pour faire un peu de cela d’abord, afin que nous puissions les rejeter proprement sans gaspiller beaucoup de CPU ou d’autres ressources.

Ajuster le test de tunnel

Plutôt que d’aller avec l’approche assez aléatoire que nous avons maintenant, nous devrions utiliser un algorithme plus conscient du contexte pour tester les tunnels. Par exemple, si nous savons déjà qu’il laisse correctement passer des données valides, il est inutile de le tester. Alors que si nous n’avons pas vu passer de données récemment, il pourrait être utile d’y envoyer des données. Cela réduira la contention du tunnel causée par un excès de messages et améliorera aussi notre vitesse de détections des tunnels en échec ainsi que notre vitesse d’intervention.

Tunnel persistant / Sélection de bail

La sélection de tunnels sortants est mise en œuvre dans 0.6.1.30, la sélection de baux entrants est mise en œuvre dans la version 0.6.2.

Sélectionner au hasard des tunnels et des baux pour chaque message crée une grande incidence de défaillance de livraison, laquelle empêche la lib streaming d' augmenter sa taille de fenêtre autant qu’elle le pourrait. En persistant avec les mêmes sélections pour une connexion donné, le taux de transfert est beaucoup plus rapide.

Compresse certaines structures de données

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.

Mise à jour du protocole ministreaming

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 inclus 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.

Implémenter protocole full streaming

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]).

Comme je l’ai dit, faire qu’I2PTunnel (et la bibliothèque ministreaming) suivent cette route était la meilleure chose à faire, mais des mécanismes plus efficaces existent. Quand nous ôtons la fonction « Mode=GUARANTEED », nous nous trouvons essentiellement avec un I2CP qui ressemble à une couche IP anonyme, et il nous sera ainsi possible de mettre en œuvre la bibliothèque de diffusion afin de profiter des expériences de conception de la couche TCP : ACK sélectifs, détection de la congestion, nagle, etc.