Usando las técnicas de abajo se ha conseguido muchas mejoras en el rendimiento. Hay más por hacer, vea la web del Rendimiento para probelmas e ideas.

Matemática nativa.

Cuando examiné el código de I2P, la mayoría del tiempo se gastaba dentro de una función: java.math. En el modPow de BigInteger. En vez de intentar mejorar este método, usamos GNU MP - una librería matemática realmente rápida (con el ensamblador mejorado para varias arquitecturas). (Editor: vea NativeBigInteger for faster public key cryptography)

ugha y duck están trabajando en el código de C/JNI, y el código java actual está desplegado con los 'ganchos' para cuando esté listo. Los resultados preliminares se ven fantásticos - ejecutar el ruter con GMP modPow nativo proporciona un aumento de velocidad del 800% , y la carga se ha reducido ala mitad. Y esto sólo ha sido en la maquina de un solo usuario, y las cosas están casi listas para ser empaquetado y distribuidas.

Envoltura Garlic par un LeaseSet de "respuesta"

Esta mejora en el algoritmo sólo afectará a las aplicaciones que quieran que los pares les responda (esto incluye todo lo que use I2PTunnel o la mini-librería de streaming de mihi):

Anteriormente, cuando Alice enviaba un mensaje a Bob, cuando Bob respondía tenía que hacer una búsqueda en la base de datos de la red - enviando varias peticiones para obtener el LeaseSet de Alice. Si ya tiene el LeaseSet de Alice, puede simplemente enviar su respuesta inmediatamente - esto es (en parte) por qué normalmente toma más tiempo conectar con alguien por primera vez, pero posteriormente es más rápido. Actualmente - para todos los clientes - empaquetamos el LeaseSet del remitente en el mensaje Garlic que es enviado al destinatario, para que cuando vaya a responder, siempre tendrán el LeaseSet almacenado localmente - eliminando completamente la necesidad de hacer búsquedas en la base de datos de la red al responder. Esto ahorra un gran ancho de banda al remitente. Si no hiciésemos las búsquedas a menudo, el uso de ancho de banda disponible global de la red descendería, ya que el destinatario no necesita hacer la búsqueda en la base de datos de la red.

Para los LeaseSets no publicados como los "clientes compartidos", esta es la única forma de enviar el LeaseSet a Bob. Desafortunadamente al construirlo cada vez se añade al menos un 100% de sobre gastos en una red con mucho ancho de banda, y mucho más en una red con mensajes más pequeños.

Los cambios programados para la versión 0.6.2 empaquetará el LeaseSet sólo cuando sea necesario, al iniciar la conexión o cuando el LeaseSet cambie. Esto reducirá sustancialmente el gasto delos mensajes I2P.

Más eficiencia en las caídas y errores del protocolo TCP

En este momento, todas las conexiones TCP hacen todas sus validaciones de pares ('peer') depués de ir a través de la negociación ('handshaking') Diffie-Hellman completa (cara) para negociar una clave de sesión privada. Esto significa que si el reloj de alguien está bastante desajustado, o sus NAT/firewall/etc no están apropiadamente configurados (o sólo están ejecutando una versión incompatible del router), van a causar consistentemente (aunque no constantemente, gracias a la lista de excluidos) una operación criptográfica cara y futil sobre todos los pares que conozcan. Aunque querremos mantener parte de las verificaciones/validaciones dentro del ámbito del cifrado, querremos actualizar el protocolo para que haga algunas de ellas primero, de forma que podamos rechazarlos limpiamente sin desperdiciar mucha CPU u otros recursos.

Ajustar las pruebas de túneles

En vez de usar el esquema bastante aleatorio que tenemos ahora, deberíamos usar un algoritmo más consciente del contexto para probar los túneles. Por ejemplo, si ya conocemos sus datos de validación correctamente, no hay necesidad de probarlo, mientras que si no hemos visto ningún dato recientemente, quizás valga la pena enviarle algunos datos. Esto reducirá el parón en los túneles debido a un número de mensajes excesivo, a la vez que mejorará la velocidad en la detección de los túneles fallidos.

Túneles persistentes / Selección del LeaseSet

La selección del túnel de salida se implementó en la versión 0.6.1.30, la selección del túnel de entrada se implementó en la versión 0.6.2.

Seleccionar los túneles y leases aleatoriamente para cada mensaje crea un gran problema con el envío de mensajes desordenados, lo cual evita que la librería de streaming pueda aumentar el tamaño de su 'ventana' tanto como podría. Al persistir con las mismas selecciones para una conexión determinada, la velocidad de transferencia es mucho mayor.

Comprimiendo algunas estructuras de datos

Los mensajes I2NP y los datos que contiene están ya definidos en una estructura bastante compacta, aunque un atributo de la estructura del RouterInfo no lo está - "options" está en texto ASCII plano en el formato nombre = valor. Ahora mismo, se está rellenado con estadísticas publicadas - alrededor de 3300 bytes por par. Implementar la compresión GZip, lo cual es trivial, ahorraría 1/3 de su tamaño, y cuando se considera las veces que se pasan las estructuras RouterInfo a través de la red, es un gran ahorro - cada vez que un ruter pregunta a otro por una entrada en la netDb que el par no posee, envía de vuelta de 3-10 estructuras RouterInfo.

Actualizar el protocolo ministreaming

Actualmente la librería ministream de mihi tiene un protocolo de negociación bastante simple - Alice envía a Bob un mensaje SYN, Bob responde con un ACK, entonces Alice y Bob comparten información, hasta que uno le envíe a otro un mensaje CLOSE. Para conexiones de larga duración (por ejemplo a un servidor IRC), esta sobrecarga es despreciable, pero para situaciones de una sola repuesta (Una petición HTTP por ejemplo), es más del doble de los mensajes necesarios. Si, de otra forma, Alice hubiese adjuntado su primer payload con el mensaje SYN, y Bob hubiese adjuntado su primera respuesta en el ACK - e incluso incluyendo la etiqueta CLOSE - los envíos transitorios como las respuetas HTTP podrían reducirse a un par de mensajes, en vez del SYN+ACK+petición+respuesta+CLOSE.

Implementar el protocolo full streaming

El protocolo ministreaming se aprovecha de una decisión en favor de un pobre diseño en el protocolo de cliente de I2P (I2CP) - la vulnerabilidad del "mode=GUARANTEED" (garantizado), que permite que lo que de otra forma sería sólo un protocolo basado en mensajes, no fiable, y que lo hace lo mejor que puede, sea utilizado para operaciones de bloqueo fiables (bajo las apariencias, todo será aún no fiable y basado en mensajes, con el router I2P proporcionando garantías de entrega al adjuntar un mensaje "ACK" `[acuse de recibo] dentro junto con la carga, de forma que una vez los datos llegan al objetivo, el mensaje ACK es reenviado de vuelta a nosotros [a través de túneles, por supuesto]).

Como ya he dicho, permitir que el I2PTunnel (y la librería ministream) usen esta ruta es lo mejor que se pudo hacer, pero hay mecanismos más eficientes. Cuando eliminamos la funcionalidad "mode=GUARANTEED", estamos esencialmente dejando un I2CP que parece una capa IP anónima, y por eso, podremos ser capaces de implementar la librería de streaming para obtener ventajas de las experiencias de diseño de la capa TCP - ACKs selectivos, detección de congestión, etc.