Importanti miglioramenti delle prestazioni sono stati ottenuti usando le tecniche che seguono. C'è ancora altro da fare, consulta la pagina delle Prestazioni per gli attuali problemi e riflessioni.

Matematica nativa

When I last profiled the I2P code, the vast majority of time was spent within one function: java.math.BigInteger's modPow. Rather than try to tune this method, we'll call out to GNU MP - an insanely fast math library (with tuned assembler for many architectures). (Editor: see NativeBigInteger for faster public key cryptography)

ugha and duck are working on the C/JNI glue code, and the existing java code is already deployed with hooks for that whenever its ready. Preliminary results look fantastic - running the router with the native GMP modPow is providing over a 800% speedup in encryption performance, and the load was cut in half. This was just on one user's machine, and things are nowhere near ready for packaging and deployment, yet.

Garlic incapsula una "risposta" LeaseSet

Questo algoritmo di tweak può avere rilievo solo per le applicazioni che richiedono che i peer rispondano loro (comunque è incluso tutto ciò che utilizza I2PTunnel o la libreria ministreaming di mihi):

In precedenza, quando Alice invia un messaggio a Bob, quando Bob risponde deve controllare nel database della rete, spedire alcune richieste per ottenere il LeaseSet attuale di Alice. Se Bob ha già l'attuale LeaseSet di Alice, può allora inviare la risposta immediatamente: questo è uno dei motivi per cui generalmente si impiega più tempo per parlare con qualcuno la prima volta che ti connetti, mentre le comunicazioni successive sono più veloci. Attualmente, per tutti i client, incapsuliamo l'attuale LeaseSet del mittente nel garlic che è spedito al destinatario: in tal modo, quando si risponderanno, il LeaseSet sarà sempre memorizzato localmente, eliminando completamente ogni necessità di controlli nel database di rete quando si risponde. Ciò impegna un'ampia porzione della larghezza di banda del mittente per ottenere una risposta veloce. Se non facessimo questo molto spesso, diminuirebbe l'utilizzo medio della larghezza di banda delle rete, visto che il destinatario non dovrebbe controllare il database di rete.

For unpublished LeaseSets such as "shared clients", this is the only way to get the LeaseSet to Bob. Unfortunately this bundling every time adds almost 100% overhead to a high-bandwidth connection, and much more to a connection with smaller messages.

Le modifiche previste per la versione 0.6.2 includeranno il LeaseSet solo quando necessario, all'inizio di una connessione o quando il LeaseSet cambia. Questo ridurrà sensibilmente il sovraccarico dello scambio messaggi di I2P.

Sistema di TCP rejection più efficiente

At the moment, all TCP connections do all of their peer validation after going through the full (expensive) Diffie-Hellman handshaking to negotiate a private session key. This means that if someone's clock is really wrong, or their NAT/firewall/etc is improperly configured (or they're just running an incompatible version of the router), they're going to consistently (though not constantly, thanks to the banlist) cause a futile expensive cryptographic operation on all the peers they know about. While we will want to keep some verification/validation within the encryption boundary, we'll want to update the protocol to do some of it first, so that we can reject them cleanly without wasting much CPU or other resources.

Impostazione del tunnel di prova

Al posto di usare lo schema abbastanza casuale che abbiamo ora, potremmo usare un algoritmo sensibile al contesto per i tunnel di test, ad esempio se noi stimiamo corretti i dati validi per passare, non c'è bisogno di testare il tunnel, mentre se recentemente non abbiamo visto passare alcun dato, forse è meglio inviare qualche dato di prova. Questo ridurrà i problemi del tunnel causati da troppi messaggi, e potrà migliorare la velocità con cui vengono rilevati - e indirizzati - i tunnel difettosi.

Tunnel persistente / Scelta della locazione

Selezione dei tunnel in uscita implementata nella versione 0.6.1.30, selezione dei lease in uscita implementata nella versione 0.6.2.

Selezionare i tunnel e i lease casualmente per ogni messaggio crea un'alta incidenza di spedizioni out-of-order: ciò impedisce che la libreria di streaming incrementi la dimensione della finestra troppo velocemente. Insistendo con le stesse selezioni per una data connessione, la velocità di trasferimento è notevolmente più alta.

Compressione di alcune strutture di dati

The I2NP messages and the data they contain is already defined in a fairly compact structure, though one attribute of the RouterInfo structure is not - "options" is a plain ASCII name = value mapping. Right now, we're filling it with those published statistics - around 3300 bytes per peer. Trivial to implement GZip compression would nearly cut that to 1/3 its size, and when you consider how often RouterInfo structures are passed across the network, that's significant savings - every time a router asks another router for a networkDb entry that the peer doesn't have, it sends back 3-10 RouterInfo of them.

Aggiornamento del protocollo di ministreaming

Currently mihi's ministreaming library has a fairly simple stream negotiation protocol - Alice sends Bob a SYN message, Bob replies with an ACK message, then Alice and Bob send each other some data, until one of them sends the other a CLOSE message. For long lasting connections (to an IRC server, for instance), that overhead is negligible, but for simple one-off request/response situations (an HTTP request/reply, for instance), that's more than twice as many messages as necessary. If, however, Alice piggybacked her first payload in with the SYN message, and Bob piggybacked his first reply with the ACK - and perhaps also included the CLOSE flag - transient streams such as HTTP requests could be reduced to a pair of messages, instead of the SYN+ACK+request+response+CLOSE.

Implementa protocollo "full streaming"

The ministreaming protocol takes advantage of a poor design decision in the I2P client protocol (I2CP) - the exposure of "mode=GUARANTEED", allowing what would otherwise be an unreliable, best-effort, message based protocol to be used for reliable, blocking operation (under the covers, its still all unreliable and message based, with the router providing delivery guarantees by garlic wrapping an "ACK" message in with the payload, so once the data gets to the target, the ACK message is forwarded back to us [through tunnels, of course]).

As I've said, having I2PTunnel (and the ministreaming lib) go this route was the best thing that could be done, but more efficient mechanisms are available. When we rip out the "mode=GUARANTEED" functionality, we're essentially leaving ourselves with an I2CP that looks like an anonymous IP layer, and as such, we'll be able to implement the streaming library to take advantage of the design experiences of the TCP layer - selective ACKs, congestion detection, nagle, etc.