msgstr "La principal implementación de cliente I2P usa Java. Si por alguna\nrazón no puede usar Java en su dispositivo, hay implementaciones\nalternativas desarrolladas por los miembros de la comunidad."
msgstr "<a href=\"%(i2pd)s\">i2pd</a> es una implementación de cliente I2P en C++.\nDesde principios de 2016, i2pd se ha vuelto lo suficientemente estable para ser usado en \nproducción, y desde el verano de 2016 implementa todas las APIs de I2P por completo."
"<a href=\"%(golang)s\">Go</a> programming language. The project is in early development."
msgstr "<a href=\"%(go_i2p)s\">Go-I2P</a> es un cliente I2P desarrollado usando el lenguage de\nprogramación <a href=\"%(golang)s\">Go</a>. El proyecto está en fase inicial de desarrollo."
msgstr "Su navegador web necesita ser configurado para poder navegar eepsites y para utilizar los outproxies disponibles en I2P. Debajo tiene un paso a paso para configurar los navegadores más populares."
msgstr "En el menú de herramientas seleccione \"Opciones de Internet\" para abrir la configuración. En la ventana de configuración seleccione la pestaña de conexiones y pulse en configuración de LAN para configurar el puerto del proxy."
"<b>Note/Privacy tip:</b> Set the FTP proxy to the same settings as the HTTP proxy."
msgstr "Ahora marque \"usar un servidor proxy para su LAN\" y \"Evitar el servidor proxy\npara direcciones locales\". Con un clic en el botón Avanzadas mostrará la ventana \npara abrir los puertos. Introduzca los valores como en la imagen, IP 127.0.0.1,\npuerto 4444, para HTTP; y puerto 4445 para HTTPS. Haciendo clic en Aceptar\nguardará la configuración, y su navegador estará listo para usar el proxy I2P.\n<b>Nota/Consejo de privacidad:</b> Configure el proxy FTP con las mismas\nconfiguraciones que el proxy HTTP."
"From the Tools menu, select Options to bring up the Firefox settings panel.\n"
"Click the icon labelled <em>Advanced</em>, then click on the <em>Network</em>\n"
"tab. In the <em>Connections</em> section, click on the Settings button. You'll\n"
"see a Window like the following:"
msgstr "Desde el menú de herramientas seleccione opciones y abra el menú de configuración de Firefox. Pulse en <em>Avanzado</em>, entonces pulse en la pestaña <em>Red</em>. En la sección de <em>Conexiones</em>, pulse el botón de Configuración. Se le mostrará una ventana como la siguiente:"
"<b>Note/Privacy tip:</b> Set the FTP proxy to the same settings as the HTTP proxy."
msgstr "En la ventana <em>Configuración de la conexión</em>, haga clic en el círculo junto\na <em>Configuración manual para proxy</em>, luego introduzca 127.0.0.1, puerto\n4444, en el campo del Proxy HTTP. Introduzca 127.0.0.1, puerto 4445, en el campo\nProxy SSL. Asegúrese de introducir localhost y 127.0.0.1 en el campo \"Sin proxy para\". \n<b>Nota/Consejo de privacidad:</b> Configure el proxy FTP con las mismas configuraciones\nque el proxy HTTP."
msgstr "Desde el menú <em>Configuraciones</em>, seleccione <em>Configurar Konqueror</em>. En el grupo\nNavegación Web en el lado izquierdo, seleccione Proxy, luego seleccione la opción \"Usar la configuración\nde proxy especificada manualmente\" a la derecha."
"<b>Note/Privacy tip:</b> Set the FTP proxy to the same settings as the HTTP proxy."
msgstr "Introduzca 127.0.0.1 y puerto 4444 en el campo HTTP. Introduzca 127.0.0.1 y puerto\n4445 en el campo HTTPS. Introduzca <code>127.0.0.1,localhost</code> en el campo Excepciones.\nHaga clic en Aplicar, y luego en Aceptar para cerrar la ventana de configuración.\n<b>Nota/Consejo de privacidad:</b> Configure el proxy FTP con las mismas configuraciones que el proxy HTTP."
msgstr "<p><b>El propio proyecto I2P no mantiene ningún servidor proxy hacia Internet.</b> \nEl único proxy de salida es un servicio del proyecto Privacy Solutions.\nConsidere realizarles una donación para la continuidad y estabilidad del\nservicio. El ancho de banda se incrementará con el incremento de los fondos\nde la organización. Quizá también habrá más proxys de salida.</p>\n<a href=\"http://privacysolutions.no\"\n target=\"_blank\">http://privacysolutions.no</a>"
msgstr "Por defecto, I2P viene configurado con dos proxys de salida: <code>%(http)s</code> \ny <code>%(https)s</code>. Aunque los nombres de dominio son diferentes, se alcanza el mismo proxy de salida.\n(residenciado/referenciado de forma múltiple para mejor rendimiento)"
msgstr "El filtrado está activo en estos proxys de salida (por ejemplo, el acceso\na Mibbit y a rastreadores (trackers) de torrents está bloqueado). Los \neepsites, que son accesibles a través de direcciones .i2p, tampoco están\npermitidos a través de los proxys de salida. Convenientemente el proxy\nde salida bloquea los servidores de publicidad."
msgstr "Si ha hecho una donación , por favor envíe un email a <a href=\"mailto:%(echelon)s\">echelon</a> con su nombre o nick (y opcionalmente su página web) para que podamos listarle aquí."
"All communication is end to end encrypted (in total there are four layers of \n"
"encryption used when sending a message), and even the end points (\"destinations\") \n"
"are cryptographic identifiers (essentially a pair of <a href=\"%(pke)s\">public keys</a>)."
msgstr "I2P es una red anónima, que presenta una capa simple que las aplicaciones pueden \nusar para enviarse mensajes entre si de forma anónima y segura. La propia red está \nestrictamente basada en mensajes (a la <a href=\"%(ip)s\">IP</a>), pero hay una librería \ndisponible para permitir comunicación en streaming fiable sobre ella (a la <a href=\"%(tcp)s\">TCP</a>). \nToda comunicación está cifrada extremo a extremo (en total hay cuatro capas de cifrado \nusadas cuando se envía un mensaje), e incluso los puntos de los extremos (\"destinos\")\nson identificadores criptográficos (esencialmente un par de <a href=\"%(pke)s\">claves públicas</a>)."
msgstr "Para a anonimizar los mensajes enviados, cada aplicación cliente tiene su \"ruter\" I2P que crea unos cuantos <a href=\"%(tunnelrouting)s\">túneles</a>\" de entrada y salida - una secuencia de pares que pasan el mensaje en una dirección (hacia y desde el cliente, respectivamente ). A su vez, cuando un cliente quiere enviar un mensaje a otro cliente, el cliente envía ese mensaje a través de uno de sus túneles de salida hacia uno de los túneles de entrada del otro cliente, eventualmente alcanzando su destino."
msgstr "La primera vez que un cliente quiere contactar con otro cliente, ambos hacen una consulta \ncontra la, completamente distribuida, \"<a href=\"%(netdb)s\">base de datos de red</a>\" - una <a href=\"%(dht)s\">tabla de hash distribuida (DHT)</a> \ncon estructura adaptada basada en el <a href=\"%(kad)s\">algoritmo Kademlia</a>. Esto se hace \npara encontrar eficientemente los túneles entrantes de los otros clientes, pero los mensajes\nsubsiguientes entre ellos normalmente incluyen esos datos, así que no se requieren \nulteriores búsquedas en la base de datos de red."
msgstr "Dentro de la red I2P las aplicaciones no tienen restricciones en como pueden comunicarse - aquellas que normalmente usan UDP pueden usar las funcionalidades básicas de I2P, y aquellas aplicaciones que normalmente usan TCP pueden utilizar la librería 'tipo TCP de streaming'. I2P incluye una aplicación genérica de puente TCP/I2P (\"<a href=\"%(i2ptunnel)s\">I2PTunnel</a>\") que permite enviar flujos TCP dentro de la red I2P, también recibir flujos TCP de fuera de la red y enviar estos a una dirección IP específica."
msgstr "El I2PTunnel se usa actualmente para dejar que la gente ejecute sus propios sitios web anónimos \n(\"eepsites\") mediante la ejecución de un servidor web normal y apuntando hacia él un 'servidor' \nI2PTunnel, al que la gente pueda acceder anónimamente sobre I2P con un navegador web \nnormal, ejecutando un proxy HTTP I2PTunnel (\"eepproxy\"). Además, usamos la misma \ntécnica para ejecutar una red IRC anónima (donde el servidor IRC está alojado anónimamente, \ny los clientes IRC estándar usan un I2PTunnel para contactar con él). Hay otros esfuerzos de \ndesarrollo de aplicaciones también en marcha, tales como uno para construir una aplicación \noptimizada de transferencia de ficheros en enjambre (estilo <a href=\"%(bittorrent)s\">BitTorrent</a>), un almacenamiento \nde datos distribuido (estilo <a href=\"%(freenet)s\">Freenet</a> / <a href=\"%(mnet)s\">MNet</a>), y un sistema de blogs (un <a href=\"%(livejournal)s\">LiveJournal</a> \ncompletamente distribuido), pero aún no están listas para su uso."
msgstr "I2P no es inherentemente una red \"outproxy\" (que haga de proxy de salida) - el cliente al que \nusted envía un mensaje es un identificador criptográfico, no una dirección IP, así que el mensaje \ndebe estar dirigido a alguien que se encuentre ejecutando I2P. Sin embargo es posible que \nesos clientes sean un proxy de salida, permitiéndole hacer un uso anónimo de sus conexiones \na Internet. Para realizar esto, el \"eepproxy\" aceptará URLs normales no-I2P (ej.: \"http://www.i2p.net\") \ny los redirigirá a un destino específico que ejecuta un proxy HTTP <a href=\"%(squid)s\">squid</a> (calamar), que permite \nla navegación anónima por la web normal de forma sencilla. Los proxys de salida simples \ncomo ese no son viables a largo plazo por varias razones (incluido el coste de ejecutar uno, \nasí como los problemas de anonimato y seguridad que conllevan), pero en ciertas \ncircunstancias la técnica podría ser apropiada."
msgstr "El <a href=\"%(team)s\">equipo</a> de desarrollo de I2P es un grupo abierto, todos los que estén interesados son bienvenidos a <a href=\"%(volunteer)s\">involucrarse</a> en el proyecto, y todo el código es <a href=\"%(licenses)s\">libre</a>. El núcleo de I2P y la implementación del ruter están en java (actualmente trabajando con sun y kaffe, el soporte para gjc está planeado para mas adelante), y hay un <a href=\"%(sam)s\"> API simple</a> para acceder a la red desde otros lenguajes (con una librería C disponible, y con Python y Perl en desarrollo). La red está en estos momentos en desarrollo activamente y aún no ha alcanzado la versión 1.0, pero la actual <a href=\"%(roadmap)s\">hoja de ruta</a> describe nuestro programa."
"Following are links to presentations, videos, and tutorials about I2P. Links"
" to research papers on I2P are available <a href=\"%(papers)s\">here</a>."
msgstr "Los siguientes enlaces son presentaciones, vídeos y tutoriales sobre I2P. Los enlaces para investigación sobre I2P están disponibles <a href=\"%(papers)s\">aquí</a>."
msgstr "<a href=\"%(video)s\">To Be or I2P</a> (Youtube Video) Una introducción a las comunicaciones anónimas con I2P. <a href=\"%(pdf)s\">To Be or I2P (PDF presentation)</a>, Jens Kubieziel, 24C3 Berlin, Diciembre 28, 2007."
msgstr "HOPE New York Julio 17, 2010 - Vista rápida sobre I2P by zzz, al final de la charla de Adrian Hong \"Hackers for Human Rights\". <a href=\"%(mp3)s\">MP3 audio</a>"
msgstr "<a href=\"%(link)s\">Usando la tecnología para mejorar la libertad</a> (Youtube Vídeo) Eric Johnson. <a href=\"http://agora.io/etienne\">Agora I/O Unconference</a>, Marzo 27, 2011. I2P desde 10:00 a 20:00 en el vídeo."
"Adrian Crenshaw, <a href=\"http://aide.marshall.edu/\">AIDE</a>, July 11-15, 2011."
msgstr "<a href=\"%(link)s\">Common Darknet Weaknesses</a> (Vídeo en Youtube) Adrian Crenshaw, <a href=\"http://aide.marshall.edu/\">AIDE</a>, Julio 11-15, 2011"
msgstr "<a href=\"%(live)s\">Cipherspaces/Darknets: An Overview Of Attack Strategies - DEF CON Vesión en vivo (Vídeo de Youtube)</a>, <a href=\"%(studio)s\">versión de \"estudio\" (Youtube Video)</a>, <a href=\"%(slides)s\">Slides (ppt)</a> Adrian Crenshaw. DEF CON 19, Las Vegas, Agosto 7, 2011."
"(Thessaloniki Tech Talk Sessions), November 4, 2011."
msgstr "<a href=\"http://0x375.org/\">Modern cipherspace ecosystems</a> (Ecosistemas de espacio cifrado modernos), 0x375 0x06 (Thessaloniki Tech Talk Sessions (Charlas técnicas de Tesalónica)), 4 de noviembre de 2011."
"Blair Dick, University of Abertay, Dundee Ethical Hacking Society, January 25, 2012."
msgstr "<a href=\"%(link)s\">I2P - The Anonymous Network</a> (I2P - La red anónima)\n(Vídeo de Youtube)\nBlair Dick, Universidad de Abertay, Sociedad de hacking ético de Dundee, 25 de enero de 2012."
"echelon, 32C3 (You Broke the Internet Assembly), Hamburg, December 28, 2015"
msgstr "<a href=\"%(link)s\">I2P - ¡Aún vive! (pdf)</a>\n<a href=\"%(link2)s\">(vídeo)</a>\nechelon, 32C3 (You Broke the Internet Assembly), Hamburgo, 28 de diciembre de 2015"
msgstr "Reemplazar criptografía débil: Actualizar la red I2P con primitivas más robustas.\n<a href=\"%(link)s\">(pdf)</a>\n<a href=\"%(link2)s\">(odp)</a>\nstr4d (desarrollador), Real World Crypto, Stanford, 8 de enero de 2016"
"str4d, COMPSCI 460: Computer Networking, University of Wisconsin Whitewater, February 17, 2016"
msgstr "Onion y Garlic: Los protocolos de I2P\n<a href=\"%(link)s\">(pdf)</a>\n<a href=\"%(link2)s\">(odp)</a>\nstr4d (desarrollador), COMPSCI 460: Computer Networking, University of Wisconsin Whitewater, 17 de febrero de 2016"
msgstr "The Invisible Internet Project - Una panorámica y guía por la tecnología\n<a href=\"%(link)s\">(mp4)</a>\n<a href=\"%(link2)s\">(webm)</a>\nAndrew Savchenko (bircoph), FOSDEM, Bruselas, 4 de febrero de 2018"
msgstr "<a href=\"%(link)s\">I2P Windows Tutorial</a> (Youtube Video) Esta guía le mostrará cono instalar I2P en Windows. Por <a href=\"http://telecomix.org/\">Telecomix</a>"
msgstr "<a href=\"%(link)s\">I2P Debian Tutorial</a> (Vídeo en Youtube) Esta guía le mostrará como instalar I2P en sistemas basados en Debian. Por <a href=\"http://telecomix.org/\">Telecomix</a>"
msgstr "<a href=\"%(link)s\">How to set up anonymous site in I2P</a> (Vídeo en Youtube) Como configurar una web anónima en I2P. Por <a href=\"http://telecomix.org/\">Telecomix</a>"
msgstr "<a href=\"%(link)s\">I2P Tutorial Mac OS X</a> (Vídeo en Youtube) Un tutorial de como ejecutar I2P en os X y como conectar a irc.telecomix.i2p. Por <a href=\"http://telecomix.org/\">Telecomix</a>"
msgstr "<a href=\"%(link)s\">Felix Atari explains the basic principles of I2P</a> (Vídeo en Youtube) Agent Felix Atari of the Telecomix Crypto Munitions Bureau. Por <a href=\"http://telecomix.org/\">Telecomix</a>"
"This tutorial shows how to install and configure software needed to access I2P."
msgstr "<a href=\"%(link)s\">How to get onto I2P, the anonymous P2P Darknet (Windows Install)</a> (Vídeo en Youtube) Esta guía muestra como instalar y configurar las aplicaciones necesarias para acceder a I2P."
msgstr "Lance James (0x90) entrevistado por DistributedCity\n<a href=\"%(link1)s\">Parte 1</a>\n<a href=\"%(link2)s\">Parte 2</a>\n26 de julio de 2002."
"(link dead, seeded inside I2P at <a href=\"http://tracker2.postman.i2p/index.php?view=TorrentDetail&id=14336\">postman's tracker</a>)"
msgstr "<a href=\"%(mp3)s\">zzz entrevistado en el InfoSec Daily Podcast Ep. 454 (mp3)</a>\n18 de agosto de 2011\n(enlace muerto, diseminado dentro de I2P por el <a href=\"http://tracker2.postman.i2p/index.php?view=TorrentDetail&id=14336\">tracker de postman</a>)"
"(link dead, seeded inside I2P at <a href=\"http://tracker2.postman.i2p/index.php?view=TorrentDetail&id=15905\">postman's tracker</a>)"
msgstr "<a href=\"%(mp3)s\">zzz y Lance James entrevistados en el InfoSec Daily Podcast Ep. 596 (mp3)</a>\n16 de febrero de 2012\n(enlace muerto, diseminado dentro de I2P por el <a href=\"http://tracker2.postman.i2p/index.php?view=TorrentDetail&id=15905\">tracker de postman</a>)"
msgstr "<a href=\"%(mp3)s\">Jeff y Str4d (desarrolladores) entrevistados en el Brakeing Down Security Podcast Ep. 2015-010 (mp3)</a>\nParte 1, 28 de febrero de 2015"
msgstr "<a href=\"%(mp3)s\">Jeff y Str4d (desarrolladores) entrevistados en el Brakeing Down Security Podcast Ep. 2015-011 (mp3)</a>\nParte 2, 6 de marzo de 2015"
msgstr "Somos un pequeño grupo de personas repartidas por varios continentes, trabajando para mejorar diferentes aspectos del proyecto y discutir el diseño de la red.<a href=\"%(volunteer)s\">¿Únete!</a>"
msgstr "I2PCon 2015 fue el primer evento de su clase. Tuvo dos metas a corto plazo.\nPrimero, ofrecer al público general un evento donde se pudiera obtener conocimiento sobre privacidad.\nSegundo, para llevar más allá al proyecto I2P y su comunidad con debates técnicos\nsobre criptografía, anonimato y temas I2P-céntricos."
"commnutiy of privacy-conscious individuals. By connecting people who recognize\n"
"the importance of privacy, we wanted to provide a forum where this community can grow."
msgstr "Una meta mayor y a más largo plazo de este evento fue construir una comunidad de\nindividuos con consciencia sobre privacidad. Al conectar personas que reconocen la\nimportancia de la privacidad, quisimos ofrecer un foro donde esta comunidad pueda crecer."
msgstr "La idea para este evento fue inicialmente concebida por nuestros\nmaravillosos amigos de <a href=\"https://torontocrypto.org/\">Toronto Crypto</a>.\nEl punto de reunión fue proporcionado por <a href=\"https://hacklab.to/\">Hacklab.to</a>.\nEl marketing fue encabezado por <a href=\"https://twitter.com/YrB1rd\">@YrB1rd</a> y Siew.\nSin ellos este evento no habría sido posible."
msgstr "Observe que esos torrents en-I2P puede que también estén disponibles en la red abierta (clearnet) debido al establecimiento de puentes por los clientes Vuze."
msgstr "Colin Mahns tiene un fuerte interés en el uso de tecnología de información y cifrado para ayudar a preservar los derechos humanos en la era digital."
"David Dagon is a postdoc researcher at Georgia Tech focused on botnets, malware, network security, and DNS.\n"
"His interest in I2P is centered on preserving user privacy, autonomous filtering, and anti-abuse."
msgstr "David Dagon es un investigador de postdoctorado en Georgia Tech enfocado en botnets, malware, seguridad de red, y DNS.\nSu interés en I2P se centra en preservar la privacidad del usuario, el filtrado autónomo, y el anti-abuso."
"He's been focused on network security, malware research, and information security ever since.\n"
"During 2011-2013, he was Director of Threat Intelligence for The Vigilant, which was acquired by Deloitte in 2013.\n"
"He recently left Deloitte to do consulting through his company The James Group."
msgstr "Lance James es el fundador del Invisible IRC Project, el predecesor de I2P, allá por 2002.\nFundó su propia compañía de inteligencia de cyber amenazas en 2003.\nDesde entonces está enfocado en la seguridad de red, investigación de malware, y seguridad de la información.\nDurante 2011-2013, fue Director de Inteligencia en Amenazas para The Vigilant, que fue adquirida por Deloitte en 2013.\nRecientemente abandonó Deloitte para hacer consultoría a través de su compañía The James Group."
"Nicholas Johnston is a Professor of Information Security in Sheridan College's School of Applied Computing in the InfoSec Bachelor's degree program.\n"
"His previous professional career was in digital forensics and investigations.\n"
msgstr "Nicholas Johnston es un Profesor de Seguridad de la Información en la Escuela de Computación Aplicada del Sheridan College en el programa de Bachelor's degree de InfoSec.\nSu carrera profesional previa fue en actividades forenses digitales e investigaciones.\nTambién es un contratista especializado en respuesta a incidentes.\nSus áreas de investigación incluyen el desarrollo de software de seguridad y el análisis de datos."
msgstr "Hay varias técnicas para mejorar el rendimiento de I2P - algunas tienen que ver con la CPU, otras con el ancho de banda y otras relacionadas con los protocolos. Sin embargo, todas estas mejoras afectan la latencia, la cantidad de datos enviados y el rendimiento de la red, mientras que reducen la competencia por los recursos escasos. Esta lista no está completa, pero abarca las más importantes que se conocen."
msgstr "Probablemente, una de las partes más importantes para conseguir una mejora en el rendimiento será mejorar como los ruters elijen los pares a través de los que construyen los túneles - asegurándose que no utiliza pares con enlaces lentos o con enlaces rápidos pero sobrecargados. etc. Además, tenemos que asegurarnos que no nos exponemos a un ataque <a href=\"%(sybilpdf)s\">Sybil</a> de un adversario con muchos recursos y con máquinas muy rápidas."
msgstr "Queremos ser más eficientes en la reparación de la base de datos de la red y los algoritmos de mantenimiento - en vez de explorar la red constantemente buscando nuevos pares - causando un gran número de mensajes y carga en el ruter - podemos frenar o incluso parar la búsqueda mientras no se detecte que hay algo nuevo por explorar (por ejemplo, ralentizar la tasa de exploración dependiendo de la última vez que algún par nos dio una referencia de algún otro par desconocido). También podemos mejorar lo que enviamos - cuantos pares recuperamos (o incluso si recuperamos una respuesta), también podemos mejorar cuantas búsquedas concurrentes hacemos."
msgstr "La forma en que funciona el algoritmo <a href=\"%(elgamalaes)s\">ElGamal/AES+SessionTag</a> es administrando un conjunto de arrays de 32 bytes aleatorios de un solo uso, y desechándolos cuando no se usan los suficientemente rápido. Si los desechamos demasiado pronto, tenemos que crear otra vez un cifrado (muy caro) ElGamal, pero si no los desechamos a tiempo, tenemos que reducir su número o nos quedaremos sin memoria RAM (y si al destinatario de alguna forma se le corrompen y pierde algunas etiquetas, pueden ocurrir incluso más fallos en los cifrados). Con algoritmos con detección activa y de control, podemos ajustar de una forma más segura y eficientemente el tiempo de vida de una etiqueta, reemplazando el cifrado ElGamal con un algoritmo más trivial como AES."
msgstr "Algunas ideas adicionales para mejorar el envío de las Etiquetas de Sesión se describen en la <a href=\"%(elgamalaes)s#future\">página de ElGamal/AES+SessionTag</a>."
msgstr "Ahora mismo, nuestro algoritmo <a href=\"%(elgamalaes)s\">ElGamal/AES+SessionTag</a> funciona etiquetando cada mensaje cifrado con un 'nonce' único de 32 bytes (una \"etiqueta de sesión\"), identificando el mensaje como un mensaje cifrado con la clave de sesión AES asociada. Esto previene que los pares distingan los mensajes que son parte de la misma sesión, ya que cada mensaje tiene una etiqueta nueva completamente aleatoria. Para llevar esto acabo, cada unos pocos mensajes se envuelven un nuevo conjunto de etiquetas de sesión dentro del mensaje cifrado, creando una forma transparente de identificar los mensajes futuros. Por lo tanto tenemos que llevar un control de cuales mensajes han llegado con éxito a su destino para saber que etiquetas debemos usar."
msgstr "Este sistema funciona bien y es muy robusto, aunque no es eficiente en el uso del ancho de banda, y necesita el envío de estas etiquetas antes de tiempo (y no todas las etiquetas serán necesarias, o se desperdician, debido al tiempo de expiración). De media, enviar con antelación las etiquetas de sesión cuesta 32 bytes por mensaje (el tamaño de una etiqueta). aunque como ha sugerido Taral, ese tamaño puede evitarse reemplazando el envío de etiquetas con un PRNG sincronizado - cuando una nueva sesión se establece (a través de un bloque cifrado ElGamal), ambos lados siembran un PRNG para generar las etiquetas de sesión cuando se necesite (con el destinatarios pre calculando los siguientes valores para poder manejar los envíos)"
msgstr "El tiempo de duración actual de 10 minutes es bastante arbitrario, aunque parece que funciona bien. Una vez que tengamos el código de reparación de túnel y un sistema de detección de fallos más eficiente, podremos cambiar estas duraciones de forma más segura, reduciendo la carga en la CPU y en la red (debido al excesivo costo al crear los mensajes de los túneles). "
"Also, it would be difficult to maintain backward compatibility with such a change."
msgstr "Esto parece un fácil arreglo para la carga de la CPU y el gasto de ancho de banda en los ruters, pero no podemos usarlos hasta que hayamos afinado mucho mejor los algoritmos de creación de túneles.\nAún así, el tiempo de vida de 10 minutos está incluido en varios sitios, con lo que hará falta bastante esfuerzo para cambiar esta duración. Además, será dificil mantener la compatibilidad con versiones anteriores tras este cambio."
msgstr "Actualmente, ya que el éxito en la creación de túneles de la red es bastante alto, no existen planes para aumentar el tiempo de vida de los túneles."
msgstr "Otros truquitos arbitrarios que parece que \"funcionan bien\" usados son los tiempos de vida actuales de varias actividades. ¿Por qué tenemos 60 segundos para el tiempo de vida de \"par inaccesible\"?¿Por qué intentamos usar un diferente túnel que el LeaseSet nos avisa después de 10 segundos?¿Por qué las consultas a la base de datos está limitada por 60 o 20 segundos?¿Por qué están las destinaciones configuradas para preguntar por un nuevo grupo de túneles cada 10 minutos?¿Por qué permitimos a un par tardar 60 segundos en responder a la petición de unirse a un túnel?¿Por qué consideramos un túnel como \"muerto\" si no pasa nuestras pruebas en 60 segundos?"
msgstr "Todos estos imponderables pueden solucionarse con un código más adaptativo, al igual que con parámetros afinables que compensen el gasto entre el ancho de banda, latencia y el uso de CPU."
msgstr "Limitación del ancho de banda en el cliente (en una o las dos direcciones de una conexión, o posiblemente compartido entre varias conexiones). Esto será además del límite general de ancho de banda, por supuesto."
msgstr "Usando las técnicas de abajo se ha conseguido muchas mejoras en el rendimiento. Hay más por hacer, vea la web del <a href=\"%(performance)s\">Rendimiento</a> para probelmas e ideas."
"<a href=\"%(jbigi)s\">NativeBigInteger for faster public key cryptography</a></i>)"
msgstr "Cuando examiné el código de I2P, la mayoría del tiempo se gastaba dentro de una función: java.math. En el <a href=\"%(modpow)s\">modPow</a> de BigInteger. En vez de intentar mejorar este método, usamos <a href=\"%(gmp)s\">GNU MP</a> - una librería matemática realmente rápida (con el ensamblador mejorado para varias arquitecturas). (<i>Editor: vea <a href=\"%(jbigi)s\">NativeBigInteger for faster public key cryptography</a></i>)"
msgstr "\nugha 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."
msgstr "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):"
msgstr "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, <i>siempre</i> 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."
msgstr "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."
msgstr "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."
msgstr "En este momento, todas las conexiones TCP hacen todas sus validaciones \nde pares ('peer') depués de ir a través de la negociación ('handshaking')\nDiffie-Hellman completa (cara) para negociar una clave de sesión privada.\nEsto significa que si el reloj de alguien está bastante desajustado, o sus \nNAT/firewall/etc no están apropiadamente configurados (o sólo están\nejecutando una versión incompatible del router), van a causar consistentemente\n(aunque no constantemente, gracias a la lista de excluidos) una operación\ncriptográfica cara y futil sobre todos los pares que conozcan. Aunque\nquerremos mantener parte de las verificaciones/validaciones dentro del\námbito del cifrado, querremos actualizar el protocolo para que haga\nalgunas de ellas primero, de forma que podamos rechazarlos \nlimpiamente sin desperdiciar mucha CPU u otros recursos."
msgstr "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."
msgstr "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."
msgstr "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."
"Currently mihi's ministreaming library has a fairly simple stream negotiation\n"
"protocol - Alice sends Bob a SYN message, Bob replies with an ACK message, then\n"
"Alice and Bob send each other some data, until one of them sends the other a\n"
"CLOSE message. For long lasting connections (to an IRC server, for instance),\n"
"that overhead is negligible, but for simple one-off request/response situations\n"
"(an HTTP request/reply, for instance), that's more than twice as many messages as\n"
"necessary. If, however, Alice piggybacked her first payload in with the SYN\n"
"message, and Bob piggybacked his first reply with the ACK - and perhaps also\n"
"included the CLOSE flag - transient streams such as HTTP requests could be\n"
"reduced to a pair of messages, instead of the SYN+ACK+request+response+CLOSE."
msgstr "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."
msgstr "El protocolo ministreaming se aprovecha de una decisión en favor de un pobre diseño\nen el protocolo de cliente de I2P (I2CP) - la vulnerabilidad del \"mode=GUARANTEED\"\n(garantizado), que permite que lo que de otra forma sería sólo un protocolo basado en\nmensajes, no fiable, y que lo hace lo mejor que puede, sea utilizado para operaciones\nde bloqueo fiables (bajo las apariencias, todo será aún no fiable y basado en mensajes,\ncon el router I2P proporcionando garantías de entrega al adjuntar un mensaje \"ACK\" `[acuse\nde recibo] dentro junto con la carga, de forma que una vez los datos llegan al objetivo,\nel mensaje ACK es reenviado de vuelta a nosotros [a través de túneles, por supuesto])."
msgstr "Como ya he <a href=\"%(link)s\">dicho</a>, 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."
msgstr "Probablemente una de las preguntas más frecuentes es ¿cómo de rápido es I2P?, y parece que a nadie le gusta la respuesta - \"depende\". Después de probar I2P, la siguiente cosa que preguntan es ¿será más rápido?, y la respuesta a eso es un enfático <b>sí</b>."
"I2P is a full dynamic network. Each client is known to other nodes and tests local known nodes for reachability and capacity.\n"
"Only reachable and capable nodes are saved to a local NetDB (This is generally only a portion of the network, around 500-1000).\n"
"When I2P builds tunnels, it selects the best resource from this pool. For example, a small subset of 20-50 nodes are only available to build tunnels with.\n"
"Because testing happens every minute, the pool of used nodes changes every minute.\n"
"Each I2P node knows a different part of the net, meaning that each router has a different set of I2P nodes to be used for tunnels.\n"
"Even if two routers have the same subset of known nodes, the tests for reachability and capacity will likely show different results, as the other routers could be under load just as one router tests, but be free if the second router tests."
msgstr "I2P es un red totalmente dinámica. Cada cliente es conocido por otros nodos y prueba los nodos conocidos localmente para comprobar su accesibilidad y su capacidad. Sólo los nodos accesibles y capaces son guardados en la NetDB local (Esto normalmente es sólo una parte de la red, sobre 500-1000). Cuando I2P construye túneles selecciona los mejores recursos de esta fuente. Por ejemplo, sólo unos 20-50 nodos están disponibles para construir túneles. Ya que las pruebas se hacen cada minuto la fuente de los nodos usados cambia cada minuto. Cada nodo I2P conoce una parte de la red total, haciendo que cada ruter tenga una lista diferente de nodos I2P para ser usados como túneles. Incluso si dos ruters tienen la misma subred de nodos conocidos las pruebas de accesibilidad y capacidad mostrarán diferentes resultados, ya que cuando un ruter hace las pruebas otros ruters pueden estar bajo carga, pero estar libre cuando es un segundo ruter el que hace las pruebas."
"The above describes why each I2P node has different nodes to build tunnels.\n"
"Because every I2P node has a different latency and bandwith, tunnels (which are built via those nodes) have different latency and bandwidth values.\n"
"And because every I2P node has different tunnels built, no two I2P nodes have the same tunnel sets."
msgstr "El texto anterior explica porque cada nodo I2P usa diferentes nodos para construir sus túneles. Porque cada nodo I2P tienen una latencia y ancho de banda diferente, los túneles ( que se construyen con estos nodos) tienen valores diferentes de latencia y ancho de banda. Y ya que cada nodo I2P tiene diferentes nodos construidos, no hay dos nodos I2P con la misma configuración de túneles."
"A server/client is known as a \"destination\" and each destination has at least one inbound and one outbound tunnel. The default is 3 hops per tunnel.\n"
"This adds up to 12 hops (aka 12 different I2P nodes) for a full roundtrip client-server-client."
msgstr "Un servidor/cliente se conoce como \"destinación\" y cada destinación tiene al menos un túnel de entrada y otro de salida. Por defecto son 3 saltos por túnel. Esto suman 12 saltos (osea 12 diferentes nodos I2P) para una ida y vuelta completa cliente-servidor-cliente."
"As the RTT (RoundTripTime) adds up from the latency of each individual I2P node and each connection on this roundtrip, it takes usually 1-3 seconds until a ack package comes back to the client.\n"
"With some internals of TCP and I2P transport, a data package has a limited size and cannot be as large as we want it to be.\n"
"Together these conditions set a limit of max bandwidth per tunnel of 20-50 kbyte/sec.\n"
"But if ONLY ONE hop in the tunnel has only 5 kb/sec bandwidth to spend, the whole tunnel is limited to 5 kb/sec, independent of the \n"
msgstr "Como la mayoría del tráfico I2P (www, torrent, ...) necesita paquetes ack hasta que la nueva información es enviada, necesita esperar hasta que un paquete ack regrese del servidor. Al final: envía información, espera por ack, envía mas información, espera por ack... Y ya que el RTT (RoundTripTime) añade latencia por cada nodo individual I2P y por cada conexión de esta ida y vuelta, normalmente tarda de 1-3 segundos hasta que un paquete ack regresa al cliente. Además el funcionamiento interno del transporte de TCP y de I2P hacen que un paquete de información tenga un tamaño limitado y no pueda ser tan grande como desearíamos que fuese. Estas condiciones unidas crean un límite de ancho de banda por túnel de 20-50 kbyte/sec. Pero, si SÓLO un salto del túnel tiene solamente 5 kb/sec de ancho de banda para usar, el túnel completo estará limitado a 5 kb/sec, independientemente de las latencia y otras limitaciones."
"Due to encryption used and other setups in I2P (howto built up tunnels, latency, ...) it is quite expensive in CPU time to build a tunnel. This is \n"
"why a destination is only allowed to have a max of 6 IN and 6 OUT tunnels to transport data. With a max of 50 kb/sec per tunnel, a destination could \n"
"use roughly 300 kb/sec traffic combined ( in reality it could be more if shorter tunnels are used with low or no anonymity available).\n"
"This change of tunnels (and sometimes clients that shutdown hard due to usage of \"shut down at once\" or situations where there is power loss) does \n"
"sometimes break tunnels and connections, as seen on the IRC2P Network in loss of connection (ping timeout) or on when using eepget."
msgstr "Debido al cifrado usado y otras configuraciones de I2P (como se construyen los túneles, latencia, ...) se utiliza bastante tiempo de la CPU para crear un túnel. Esto es por lo que una destinación solo tiene permitido un máximo de 6 túneles de de entrada y 6 de salida para enviar información. Con un máximo de 50 kb/sec por túnel una destinación podría usar aproximadamente 300 kb/sec (en realidad podría ser más si se utilizan túneles más cortos con poco o ningún anonimato). Los túneles usados son eliminados cada 10 minutos y se crean unos nuevos. Estos cambios en los túneles (y a veces los clientes que apagan de golpe usando \"apagar inmediatamente\" o por caídas de corriente) a veces rompen los túneles y las conexiones, como se puede ver en las pérdidas de conexiones en el IRC2P (ping timeout) o cuando se está usando eepget."
"With a limited set of destinations and a limited set of tunnels per destination, one I2P node only uses a limited set of tunnels across other I2P nodes.\n"
"For example, if an I2P node is \"hop1\" in the small example above, we only see 1 participating tunnel originating from the client.\n"
"If we sum up the whole I2P network, only a rather limited number of participating tunnels could be built with a limited amount of bandwidth all together.\n"
"If one distributes these limited numbers across the number of I2P nodes, there is only a fraction of available bandwidth/capacity available for use."
msgstr "Con un número limitado de destinaciones y un número limitado de túneles por destinación, un nodo I2P sólo utiliza un número limitado de túneles a través de otros nodos de I2P. Por ejemplo, si en el ejemplo de arriba un nodo I2P es \"hop1\", sólo tendríamos 1 túnel participante originado en el cliente. Si sumamos toda la red I2P, sólo un número limitado de túneles participantes pueden ser construidos con una cantidad limitada de ancho de banda. Si uno distribuye todo ese número limitado entre el número de nodos I2P, sólo hay disponible una fracción del ancho de banca/capacidad disponible para el uso."
"To remain anonymous one router should not be used by the whole network for building tunnels.\n"
"If one router does act as a tunnel router for ALL I2P nodes, it becomes a very real central point of failure as well as a central point to grab IPs and data from the clients. This is not good.\n"
"I2P attempts to spread the load across a lot of I2P nodes because of this reason."
msgstr "Para permanecer anónimos un ruter no debería usarse por toda la red para construir túneles, si un solo ruter funciona como túnel para TODOS los nodos de I2P se convierte en el centro de un problema, así como el punto central para obtener IPs e información de los clientes. Esto no es bueno. I2P intenta repartir la carga a través de muchos nodos I2P justo por esta razón."
"Another point is the full mesh network. Each connection hop-hop utilizes one TCP or UDP connection on the I2P nodes. With 1000 connections, one sees \n"
"1000 TCP connections. That is quite a lot and some home and small office routers (DSL, cable,..) only allow a small number of connections (or just go mad if you use more than X connections).\n"
"I2P tries to limit these connections to be under 1500 per UDP and per TCP type.\n"
msgstr "Otro punto a tener en cuenta es la red mesh completa. Cada conexión salto-a-salto utiliza una conexión TCP o UDP en los nodos de I2P. Con 1000 conexiones uno ve 1000 conexiones TCP. Eso es bastante y algunos ruters domésticos o de oficina (DSL, cable...) sólo permiten un cierto número de conexiones ( o simplemente se vuelven locos si se usa un número mayor de X conexiones). I2P intenta limitar esas conexiones por debajo de 1500 para UDP y TCP. Esto limita también la cantidad de tráfico enrutado a través de su nodo I2P."
"In summary, I2P is very complex and there is no easy way to pinpoint why your node is not used.\n"
"If your node is reachable and has a bandwidth setting of >128 kbyte/sec shared and is reachable 24/7, it should be used after some time for participating traffic.\n"
"If it is down in between, the testing of your I2P node done by other nodes will tell them: you are not reachable. This blocks your node for at least \n"
"24h on other nodes. So, the other nodes which tested you as down will not use your node for 24h for building tunnels. This is why your traffic will \n"
msgstr "En resumen, I2P es muy complejo y no hay una forma fácil de determinar con precisión por qué su nodo no se utiliza. Si su ruter es accesible y tiene mas de 128 kbyte/sec de ancho de banda compartido y está accesible 24/7, debería ser usado después de algún tiempo de tener tráfico participante. Si no esta activo siempre, las pruebas de otros nodos sobre su nodo I2P le dirá: no está accesible. Esto bloquea su nodo por al menos 24h para los otros nodos. Por lo cual los otros nodos que han testado su nodo cuando estaba caído no utilizarán su nodo para construir túneles durante 24h. Esto es por lo que su tráfico será menor después de un reinicio/apagado por lo menos durante 24h."
"Also: other I2P nodes needs to know your I2P router to test it for reachability and capacity. It takes time for other nodes to get known to your node. \n"
"It will be faster if you use I2P and build more tunnels, e.g. use a torrent or www for some time."
msgstr "Además: otros nodos I2P necesitan conocer su ruter I2P para probar la accesibilidad y capacidad. Toma tiempo que otros nodos lleguen a conocer su nodo. Será más rápido si utiliza I2P y crea más túneles, por ejemplo usando torrents o webs i2p durante algún tiempo."
