Aquí hay un esquema para una aplicación proxy WWW mínima para usar sobre I2P
Usar HTTP sobre I2P usando un I2PTunnel. Cuando la librería base SocketLibrary esté lista, los únicos cambios significantes serán que el 'wrapRequest' y 'unwrapRequest' serán alojados funcionalmente en la librería socketLibrary, no en el ruter (pero las versiones más nuevas de SocketLibrary serán capaces de usar ACK selectivo y windows de grandes tamaños, permitiendo que sean omitidos más Acks)
---BROWSER--->-I2PTUNNEL--->-ROUTERA--->-ROUTERB--->-I2PTUNNEL--->-HTTPD---------- 1: openCon 2: requestCon 3: wrapRequest 4: unwrapRequest 5: receiveACK receiveCon 6: sentSuccess sendSYN 7: wrapRequest 8: unwrapRequest 9: receiveSYN receiveACK 10: "GET /" sentSuccess 11: sendData 12: wrapRequest 13: unwrapRequest 14: receiveACK receiveData 15: sentSuccess "GET /" 16: "HTTP 200\n\nHi" 17: sendData 18: wrapRequest 19: unwrapRequest 20: receiveData receiveACK 21: "HTTP 200\n\nHi" sentSuccess 22: closeCon 23: sendClose 24: wrapRequest 25: unwrapRequest 26: receiveACK receiveClose 27: sentSuccess
Un clase optimizada, diseñada para manejar archivos y páginas de sólo128KB [1], pude funcionar mucho más rápida:
BROWSER --> MinWWW --> ROUTERA --> ROUTERB --> MinWWW --> HTTPD 1: openCon 2: opened 3: "GET /" 4: sendData 5: forward 6: receive 7: receiveData 8: "GET /" 9: "HTTP 200\n\nHi" 10: sendData 11: forward 12: receive 13: receiveData 14: "HTTP 200\n\nHi" 15: closeCon 16: closed
La diferencia en la carga y latencia de la red es significante - esto es esencialmente una versión UDP de HTTP. En las webs normales no podemos hacer esto, ya que la mayoría de las peticiones y respuestas HTTP son mayores de lo que permiten los paquetes UDP, pero en I2P, los mensajes pueden ser más grandes. El ahorro para la red viene de que no necesitamos enviar ningún mensaje ACK - al contrario que las peticiones wrap/unwrap anteriores (que unen un DataMessage con un DeliveryStatusMessage para asegurarse que que ha sido entregado), el proxy MinWWW se encarga de estos reenvíos (si es necesario - en los I2PTunnel no hay reenvíos).
Los datos que el servidor y el proxy MinWWW necesitan envolver son triviales - cuando el proxy quiere enviar un "GET /", lo antepone con la destinación I2P y envía la petición, seguido por un ID de petición de 4 bytes. El servidor MinWWW recibe entonces estas peticiones, contacta con el servidor HTTP apropiado, envía la petición, espera por la respuesta, y envía una respuesta al proxy MinWWW con la respuesta dentro, y con el ID original de la petición como prefijo. Esa respuesta se toma y se envía de vuelta al navegador, y se cierra la conexión.
Además, el proxy MinWWW puede elegir el servidor MinWWW a usar de una lista, a través de round robin u otro algoritmo, con lo que habría múltiples outproxies unidos transparentemente. El ancho de banda necesario para ejecutar estos outproxies se reduce drásticamente, ya que sólo maneja archivos de 128KB (tambien conocido como: nadie va a bajar porno, software, etc).
Esta funcionalidad /está/ limitada, pero 128KB es mucho para una simple respuesta o petición HTTP. Los diagramas de más arriba además no son realistas en sus saltos - ROUTERA nunca conectará directamente con ROUTERB, ROUTERA enviará sus mensajes a través de dos ruters de salida adicionales, entonces se reenviará a dos túneles adicionales hacia ROUTERB, con lo que el retraso es significante - mientras que lo anterior sólo ahorra 11 pasos, 8 de estos pasos necesitan atravesar el camino entero de túneles (4 saltos más remotos cada vez), dejando MinWWW con sólo dos recorridos completos (uno para la petición, otro para la respuesta), en vez de 10.
Implementar el proxy y el servidor MinWWW debería ser bastante fácil - leer una petición HTTP del cliente (quizás sólo empezar con un HTTP GET; dejando HTTP POST para más tarde), envolver el mensaje, y esperar por la respuesta. El servidor de turno sólo necesita analizar la petición para abrir un socket o una URL, enviar la petición, esperar por la respuesta y enviarlo de vuelta a través de la red. ¡Si alguien implementase esto, sería Genial! :)
[1] ¿Por qué archivos de 128KB? Actualmente I2P permite mensajes de tamaño arbitrario, pero eso se eliminará ya que implica un gasto de memoria en los ruters intermedios. Los túneles I2P están limitados a 128KB y no ha sido un problema, son lo que quizás podría ampliarse a 256KB cuando las espcificaciones de I2CP se actualicen)