I2P Router Help
In terms of memory usage, I2P is configured to use 128 MB of RAM by default. This is sufficient for browsing and IRC usage. However, other activities may require greater memory allocation. For example, if one wishes to run a high-bandwidth router, participate in I2P torrents or serve high-traffic hidden services, a higher amount of memory is required.
In terms of CPU usage, I2P has been tested to run on modest systems such as the Raspberry Pi range of single-board computers. As I2P makes heavy use of cryptographic techniques, a stronger CPU will be better suited to handle the workload generated by I2P as well as tasks related to the rest of the system (i.e. Operating System, GUI, Other processes e.g. Web Browsing).
A comparison of some of the available Java Runtime Environments (JRE) is available here: https://trac.i2p2.de/wiki/java. Using Sun/Oracle Java or OpenJDK is recommended.
Embora a principal implementação do cliente I2P requeira Java, existem vários clientes alternativo que não requerem Java.
Formerly called an eepSite, an I2P Site is a website that is hosted anonymously, a hidden service which is accessible through your web browser. It can be accessed by setting your web browser's HTTP proxy to use the I2P web proxy (typically it listens on localhost port 4444), and browsing to the site. Detailed instructions for configuring your browse can be found on the browser configuration page.
x is the number of peers you've sent or received a message from successfully in the last minute, y is the number of peers seen in the last hour or so. Try hovering your cursor over the other lines of information for a brief description.
I2P is an anonymous network - it is designed to withstand attempts at blocking or censoring of content, thus providing a means for communication that anyone can use. I2P traffic that transits through your router is encrypted with several layers of encryption. Except in the case of a serious security vulnerability (of which none are currently known), it is not possible to know what the contents of the traffic are and thus not possible to distinguish between traffic which one is opposed to or not opposed to. We consider the 3 parts of the question:
All traffic on I2P is encrypted in multiple layers. You don't know a message's contents, source, or destination. All traffic you route is internal to the I2P network, you are not an exit node (referred to as an outproxy in our documentation). Your only alternative is to refuse to route any traffic, by setting your share bandwidth or maximum participating tunnels to 0 (see above). It would be nice if you didn't do this, you should help the network by routing traffic for others. Over 95% of users route traffic for others.
I2P does not do distributed storage of content, this has to be specifically installed and configured by the user (with Tahoe-LAFS, for example). That is a feature of a different anonymous network, Freenet. By running I2P, you are not storing content for anyone.
If there are hidden services which you dislike, you may refrain from visiting them. Your router will not request any content without your specific instruction to do so.
Yes, by far the easiest and most common way is by blocking bootstrap, or "Reseed" servers. Completely blocking all obfuscated traffic would work as well (although it would break many, many other things that are not I2P and most are not willing to go this far). In the case of reseed blocking, there is a reseed bundle on Github, blocking it will also block Github. You can reseed over a proxy (many can be found on Internet if you do not want to use Tor) or share reseed bundles on a friend-to-friend basis offline.
Este erro ocorrerá frequentemente em qualquer rede com um software Java ativado em sistemas que estão configurados para usar o IPV6 por padrão. Há algumas maneiras de resolver isso:
Em sistemas Linux você pode fazer
echo 0 > /proc/sys/net/ipv6/bindv6only
- Procure pelas seguintes linhas em
Se as linhas estão lá, descomente-as removendo os "#". Se não estão, adicione-as sem "#".
ALERTA: Qualquer que seja a mudança feita em
wrapper.config, para surtir efeito, é necessário interromper completamente
o roteador e o encapsulador. Ao clicar em Reinicializar no painel do seu
roteador o arquivo NÃO é lido novamente! É preciso que você
clique em Desligar, aguarde 11 minutos e, então, inicialize o software I2P.
If you consider every I2P Site that has ever been created, yes, most of them are down. People and I2P Sites come and go. A good way to get started in I2P is check out a list of I2P Sites that are currently up. http://identiguy.i2p.xyz tracks active I2P Sites.
The Tanuki java service wrapper that we use opens this port —bound to localhost— in order to communicate with software running inside the JVM. When the JVM is launched it is given a key so it can connect to the wrapper. After the JVM establishes its connection to the wrapper, the wrapper refuses any additional connections.
More information can be found in the wrapper documentation.
The proxy config for different browsers is on a separate page with screenshots. More advanced configs with external tools, such as the browser plug-in FoxyProxy or the proxy server Privoxy, are possible but could introduce leaks in your setup.
A tunnel to the main IRC server within I2P, Irc2P, is created when I2P is installed (see the I2PTunnel configuration page), and is automatically started when the I2P router starts.
To connect to it, tell your IRC client to connect to
HexChat-like client users can create a new network with the server
localhost/6668 (remember to tick "Bypass proxy server" if you have a proxy server configured).
Weechat users can use the following command to add a new network:
/server add irc2p localhost/6668
Para instruções, clique no link do Website no topo do painel do seu roteador.
If I host a website at I2P at home, containing only HTML and CSS, is it dangerous?
If you're hosting a personal blog or doing something otherwise non-sensitive, then you are obviously in little danger. If you have privacy needs that are basically non-specific, you are in little danger. If you are hosting something sensitive, then your services will go down at the same time that your router goes down. Someone who observes your downtime and correlates it to real-world events could probably de-anonymize you with enough effort. I2P has defenses available against this like multihoming or Tahoe-LAFS, but they require additional set up and are only appropriate for some threat models. There is no magic solution, protecting yourself from a real threat will take real consideration in any case.
How Does I2P find ".i2p" websites?
The I2P Address Book application maps human-readable names to long-term destinations, associated with services, making it more like a hosts file or a contact list than a network database or a DNS service. It's also local-first there is no recognized global namespace, you decide what any given .i2p domain maps to in the end. The middle-ground is something called a "Jump Service" which provides a human-readable name by redirecting you to a page where you will be asked "Do you give the I2P router permission to call $SITE_CRYPTO_KEY the name $SITE_NAME.i2p" or something to that effect. Once it's in your address book, you can generate your own jump URL's to help share the site with others.
How do I add addresses to the Address Book?
You cannot add an address without knowing at least the base32 or base64 of the site you want to visit. The "hostname" which is human-readable is only an alias for the cryptographic address, which corresponds to the base32 or base64. Without the cryptographic address, there is no way to access an I2P Site, this is by design. Distributing the address to people who do not know it yet is usually the responsibility of the Jump service provider. Visiting an I2P Site which is unknown will trigger the use of a Jump service. stats.i2p is the most reliable Jump service.
If you're hosting a site via i2ptunnel, then it won't have a registration with a jump service yet. To give it a URL locally, then visit the configuration page and click the button that says "Add to Local Address Book." Then go to http://127.0.0.1:7657/dns to look up the addresshelper URL and share it.
As portas que são utilizadas pela I2P podem ser divididas em 2 grupos:
- Internet-facing ports, which are used for communication with other I2P routers
- Portas locais, para conexões locais
Estes são descritos em detalhes abaixo.
- Internet-facing ports
Note: Since release 0.7.8, new installs do not use port 8887; a random port between 9000 and 31000 is selected when the program is run for the first time. The selected port is shown on the router configuration page.
- UDP from the random port listed on the configuration page to arbitrary remote UDP ports, allowing for replies
- TCP from random high ports to arbitrary remote TCP ports
- Outbound UDP on port 123, allowing for replies. This is necessary for I2P's internal time sync (via SNTP - querying a random SNTP host in pool.ntp.org or another server you specify)
- Local I2P ports, listening only to local connections by default, except where noted:
PORTA PROPÓSITO DESCRIÇÃO 1900 UPnP SSDP UDP multicast listener Cannot be changed. Binds to all interfaces. May be disabled on confignet. 2827 BOB bridge A higher level socket API for clients. Disabled by default. May be enabled/disabled on configclients. May be changed in the bob.config file. 4444 HTTP proxy May be disabled or changed on the i2ptunnel page in the router console. May also be configured to be bound to a specific interface or all interfaces. 4445 HTTPS proxy May be disabled or changed on the i2ptunnel page in the router console. May also be configured to be bound to a specific interface or all interfaces. 6668 IRC proxy May be disabled or changed on the i2ptunnel page in the router console. May also be configured to be bound to a specific interface or all interfaces. 7652 HTTP TCP event listener Binds to the LAN address. May be changed with advanced config
i2np.upnp.HTTPPort=nnnn. May be disabled on confignet.
7653 UPnP SSDP UDP search response listener Binds to the LAN address. May be changed with advanced config
i2np.upnp.SSDPPort=nnnn. May be disabled on confignet.
7654 I2P Client Protocol port Used by client apps. May be changed to a different port on configclients but this is not recommended. May be to bind to a different interface or all interfaces, or disabled, on configclients. 7655 UDP for SAM bridge A higher level socket API for clients Only opened when a SAM V3 client requests a UDP session. May be enabled/disabled on configclients. May be changed in the
clients.configfile with the SAM command line option
7656 SAM bridge A higher level socket API for clients Disabled by default for new installs as of release 0.6.5. May be enabled/disabled on configclients. May be changed in the
7657 Your router console May be disabled in the
clients.configfile. May also be configured to be bound to a specific interface or all interfaces in that file.
7658 Your I2P Site May be disabled in the
clients.configfile. May also be configured to be bound to a specific interface or all interfaces in the
7659 Outgoing mail to smtp.postman.i2p 7660 Incoming mail from pop3.postman.i2p 7670 (8998) gitssh.idk.i2p git over ssh This used to be port 8998 for monotone. Elder installations may still have that and not this one. May be disabled or changed on the i2ptunnel page in the router console. May also be configured to be bound to a specific interface or all interfaces. 31000 Local connection to the wrapper control channel port Outbound to 32000 only, does not listen on this port. Starts at 31000 and will increment until 31999 looking for a free port. To change, see the wrapper documentation. For more information see below. 32000 Local control channel for the service wrapper To change, see the wrapper documentation. For more information see below.
As portas locais I2P e as portas I2PTunnel não precisam ser acessíveis a partir de máquinas remotas, mas *deveriam* ser acessíveis localmente. Você também pode criar portas adicionais para instâncias do I2PTunnel via http://localhost:7657/i2ptunnel/ (e, por sua vez, precisará permitir acesso local em seu firewall, mas não acesso remoto, a menos que você o deseje dessa forma).
Em resumo, nada precisa ser acessível por pares remotos não solicitados, mas, se você puder configurar seu NAT/firewall para permitir conexões entrante UDP e TCP para porta de escuta e saída, você terá melhor desempenho. Você também precisará ser capaz de enviar pacotes UDP de saída para pares remotos arbitrários (bloquear aleatoriamente IPs com coisas como PeerGuardian só prejudica você - não o faça).
Essa questão pode ser respondida em 3 partes:
- My router often displays a message saying "Website Not Found In Address Book", why do I see this message?
Human-readable addresses such as http://website.i2p are references to a long, random string known as a destination. These references are registered and stored at address book services such as stats.i2p, which is run by zzz. You will often encounter a "b32" address. A "b32" is a hash (specifically, a SHA256 hash) of the destination. This hash is appended with ".b32.i2p" and serves as a convenient way to link to your hidden service, without requiring any registration on an address book service.
It is possible to add subscriptions to your router's configuration which may reduce the frequency of these messages.
- What is an address book subscription?
This is a list of files hosted on various I2P websites each of which contain a list of I2P hosts and their associated destinations.
The address book is located at http://localhost:7657/dns where further information can be found.
- What are some good address book subscription links?
You may try the following:
For security purposes, the router's admin console by default only listens for connections on the local interface. There are two methods for accessing the console remotely:
- Túnel SSH
- Configuring your console to be available on a Public IP address with a username & password
Estes são detalhados abaixo:
- Túnel SSH
If you are running a Unix-like Operating System, this is the easiest method for remotely accessing your I2P console. (Note: SSH server software is available for systems running Windows, for example https://github.com/PowerShell/Win32-OpenSSH)
Once you have configured SSH access to your system, the '-L' flag is passed to SSH with appropriate arguments - for example:
ssh -L 7657:localhost:7657 (System_IP)
ssh -NL 7657:localhost:7657 (System_IP)
- Configuring your console to be available on a Public IP address with a username & password
clientApp.0.args=7657 ::1,127.0.0.1 ./webapps/
clientApp.0.args=7657 ::1,127.0.0.1,(System_IP) ./webapps/
- Go to http://localhost:7657/configui and add a console username and password if desired - Adding a username & password is highly recommended to secure your I2P console from tampering, which could lead to de-anonymization.
- Go to http://localhost:7657/index and hit "Graceful restart", which restarts the JVM and reloads the client applications
http://(System_IP):7657and you will be prompted for the username and password you specified in step 2 above if your browser supports the authentication popup.
NOTE: You can specify 0.0.0.0 in the above configuration. This specifies an interface, not a network or netmask. 0.0.0.0 means "bind to all interfaces", so it can be reachable on 127.0.0.1:7657 as well as any LAN/WAN IP. Be careful when using this option as the console will be available on ALL addresses configured on your system.
Please see the previous answer for instructions on using SSH Port Forwarding, and also see this page in your console: http://localhost:7657/configi2cp
The SOCKS proxy has been functional since release 0.7.1. SOCKS 4/4a/5 are supported. I2P does not have a SOCKS outproxy so it is limited to use within I2P only.
Many applications leak sensitive information that could identify you on the Internet and this is a risk that one should be aware of when using the I2P SOCKS proxy. I2P only filters connection data, but if the program you intend to run sends this information as content, I2P has no way to protect your anonymity. For example, some mail applications will send the IP address of the machine they are running on to a mail server. There is no way for I2P to filter this, thus using I2P to 'socksify' existing applications is possible, but extremely dangerous.
Se você ainda quiser mais informações sobre socks proxy, há algumas dicas úteis emsite do socks.
Unless an outproxy has been specifically set up for the service you want to connect to, this cannot be done. There are only three types of outproxies running right now: HTTP, HTTPS, and email. Note that there is no SOCKS outproxy. If this type of service is required, we recommend that you use Tor. Please be aware that the Tor project recommends against using BitTorrent over Tor, as there are serious anonymity-related issues associated with doing so.
Privacy and Safety
No. Unlike Tor, "exit nodes" - or "outproxies" as they are referred to on the I2P network - are not an inherent part of the network. Only volunteers who specifically set up and run separate applications will relay traffic to the regular Internet. There are very, very few of these. By default, I2P's HTTP Proxy (configured to run on port 4444) includes a single outproxy: false.i2p. This is run on a voluntary basis by Meeh. There is an outproxy guide available on our forums, if you would like to learn more about running an outproxy.
Before you use I2P, use Basic Computer Hygiene Always! Apply your OS vendor provided software updates in a prompt manner. Be aware of the state of your firewall and anti-virus status if you use one. Always get your software from authentic sources.
I2P strives to be safe in it's default configuration for all users.
It may be dangerous to use I2P in what the project calls "Strict Countries" where the law may not be clear on anonymizing software and where risks are judged to be fairly high. Most I2P peers are not in those strict countries and the ones that are, are placed in "Hidden Mode" where they interact with the rest of the network in more limited ways, so that they are less visible to network observers.
Yes, and this is how a fully distributed peer-to-peer network works. Every node participates in routing packets for others, so your IP address must be known to establish connections.
While the fact that your computer runs I2P is public, nobody can see your activities in it. You can't say if a user behind this IP address is sharing files, hosting a website, doing research or just running a node to contribute bandwidth to the project.
It can be deduced that somebody is using the I2P network with some reliability, but it is a little difficult to know for sure. The most reliable way to know for sure would be to have a computer with a fairly stable IP address that you suspect is an I2P user, and a bunch of computers you control on different networks all running I2P. When one of them connects to your suspected computer, you will be able to see their I2P router in the netDB. This might take time, and it might never happen. You could also try blocking all obfuscated traffic on a particular network until you're sure every I2P router on that network has lost all of it's peers. At that point, they'll reach out to reseed servers to get more peers, which a network administrator can probably observe.
I2P does not encrypt the Internet, neither does Tor - for example, through Transport Layer Security (TLS). I2P and Tor both aim to transport your traffic as-is securely and anonymously over the corresponding network, to its destination. Any unencrypted traffic generated at your system will arrive at the outproxy (on I2P) or the exit node (on Tor) as unencrypted traffic. This means that you are vulnerable to snooping by the outproxy operators. One way to protect your outproxy traffic against this is to ensure that any traffic that will be handled by the outproxy is encrypted with TLS.
Para mais informação, pode ler a resposta do Tor FAQ a esta questão: https://www.torproject.org/docs/faq#CanExitNodesEavesdrop
In addition, you may be vulnerable to collusion between the outproxy operator and operators of other I2P services, if you use the same tunnels ("shared clients"). There is additional discussion about this on zzz.i2p. This discussion has been mirrored on our forums as well.
Ultimately, this is a question that only you can answer because the correct answer depends on your browsing behaviour, your threat model, and how much you choose to trust the outproxy operator.
Reducing anonymity is typically done by A) identifying characteristics that are consistent across anonymous identities or B) identifying ephemeral characteristics of repeated connections. We say "reducing" anonymity because many of these characteristics are shared by many of our users, making these anonymity "sets," the smaller the anonymity set and the more small sets you belong to, the more brittle your anonymity.
Attacks on I2P in the past have relied on correlating NetDB storage and verification, by randomizing the delay between storage and verification, we reduce the consistency with which that verification can be linked to I2P activity, thereby limiting the utility of that data point.
Attacks on software configured to work with I2P are out of scope for I2P to solve. When browsing I2P or hosting I2P services, it's is the responsibility of the user to consider their threat model. Browsers are particularly problematic due to fingerprinting attacks, and the wide variety of information that can be gleaned from them. Using a standardized browsing profile is thought to help mitigate the impact of fingerprinting.
New installations of I2P carry out the reseeding process automatically, as well as when the number of known peers falls to a drastically low value. If you need to carry out a reseed of your router, please see the reseed instructions.
An I2P router only needs to be seeded once, to join the network for the first time. Reseeding involves fetching multiple "RouterInfo" files (bundled into a signed zip-file) from at least two predefined server URLs picked from a volunteer-run group of non-private internet HTTPS servers.
Um sintoma típico de uma repropagação falhada é o indicador "Conhecido" (na barra lateral esquerda do painel do roteador) mostrando um valor muito pequeno (muitas vezes inferior a 5) que não aumenta. Isto pode ocorrer, entre outras coisas, se seu firewall local limitar o tráfego de saída ou se o pedido de repropagação for totalmente bloqueado.
Se você estiver preso atrás de um firewall ou filtro de seu provedor de internet, você pode usar o seguinte método manual (solução técnica não-automatizada) para aderir a rede I2P.
A partir do lançamento 0.9.33, você também pode configurar seu roteador I2P para ser repropagado via proxy. Vá para http://localhost:7657/configreseed e configure o tipo de proxy, nome do host, e porta.
Juntar-se à Rede I2P utilizando um arquivo de repropagação
Entre em contato com um amigo que você conhece e confia que tenha um Roteador I2P em funcionamento, e peça que o ajude com a repropagação de seu Roteador I2P. Peça-lhe que lhe envie um arquivo de repropagação exportado de seu Roteador I2P em funcionamento. É vital que o arquivo seja trocado através de um canal seguro, por exemplo, criptografado para evitar adulterações externas (PGP Assinado, Criptografado e Verificado com uma chave pública de confiança). O arquivo em si não está assinado, portanto, por favor, apenas aceite arquivos somente de amigos que você sabe confiar. Nunca importe um arquivo de repropagação se você não pode verificar sua procedência.
Para importar o arquivo i2preseed.ziprecebido para seu Roteador I2P:
- Siga para http://localhost:7657/configreseed
- Em "Repropagação Manual do Arquivo" clique em "Procurar..."
- Selecione o arquivo i2preseed.zip
- Clique em "Repropagar do Arquivo"
Verifique o registro para a seguinte mensagem:
Reseed got 100 router infos from file with 0 errors
Compartilhamento de um arquivo de repropagação
Para amigos de confiança você pode usar seu roteador I2P local para dar a eles um salto:
- Siga para http://localhost:7657/configreseed
- Em "Criar Arquivo de Repropagação" clique em "Criar Arquivo de Repropagação"
- Envie com segurança o arquivo i2preseed.zip para seu amigo
Não revele este arquivo a usuários desconhecidos em nenhuma circunstância, pois ele contém dados privado sensíveis (100 informeDeRoteador) de seu próprio roteador I2P! Para proteger seu anonimato: você pode esperar algumas horas/dias antes de você compartilhar o arquivo com seu amigo de confiança. Também é aconselhável usar este procedimento com moderação (< 2 por semana).
Diretrizes gerais para repropagação manual do I2P
- Não publique publicamente o arquivo de repropagação ou compartilhe estes arquivos com um amigo de um amigo!
- Este arquivo deve ser usado somente para um número muito limitado de amigos (< 3)!
- O arquivo é válido apenas por alguns dias (< 20)!
I2P is primarily not intended, nor designed, to be used as a proxy to the regular internet. With that said, there are services which are provided by volunteers that act as proxies to non-private internet based content - these are referred to as "outproxies" on the I2P network. There is an outproxy configured by default in I2P's HTTP client tunnel - false.i2p. While this service does currently exist, there is no guarantee that it will always be there as it is not an official service provided by the I2P project. If your main requirement from an anonymous network is the ability to access non-private internet resources, we would recommend using Tor.
Within I2P, there is no requirement to use HTTPS. All traffic is encrypted end-to-end, any further encryption, e.g. with the use of HTTPS, doesn't create any further anonymity-related benefits. However, if one would like to use HTTPS or has a requirement to do so, the existing default I2P HTTP Proxy has support for HTTPS traffic. Any hidden service operator would have to specifically set up and enable HTTPS access.
FTP is not supported for technical reasons. There are no FTP "outproxies" to the Internet—it may not even be possible to set up one. Any other kind of outproxy may work if it's set up with a standard tunnel. If you would like to set up some type of outproxy, carefully research the potential risks. The I2P community may or may not be able to help with the technical aspects, feel free to ask. As explained several times above, any existing outproxy isn't a core part of the network. They are services run by individuals and they may or may not be operational at any given time.
Podemos listar muitas causas para o alto uso de CPU. Eis aqui uma lista:
Java Runtime Environment
Try to use either OpenJDK or Sun/Oracle Java if it's available for your system. You can check which version of java you have installed by typing
java -versionat a command/shell prompt. Performance tends to suffer with other implementations of java.
File sharing applications, e.g. BitTorrent
Você está rodando um cliente BitTorrent através do I2P? Tente reduzir o numero de torrents, os limites de banda, ou tente desliga-lo completamente e veja se isso ajuda.
High bandwidth settings
Os seus limites de banda estão muito altos? É possivel que muito trafego esteja passando através do seu roteador I2P e o está sobrecarregando. Tente reduzir as configurações para compartilhar porcentagem de banda na pagina de configurações.
Versão da I2P
Tenha certeza de que você está utilizando a última versão do I2P para obter os benefícios de aumento de desempenho e correção de bugs.
Alocação de memória
Has enough memory been set aside for use by I2P? Look at the memory graph on the graphs page to see if the memory usage is "pegged"—the JVM is spending most of its time in garbage collection. Increase the setting
wrapper.java.maxmemoryin the file
Bursts of high-usage vs. constant 100% usage
Is the CPU usage simply higher than you would like, or is it pegged at 100% for a long time? If it is pegged, this could be a bug. Look in the logs for clues.
Relacionado a Java
Talvez você esteja usando a biblioteca baseada no BigInteger do Java, ao invés da versão nativa, especialmente se estiver executando em hardware ou SO recentes ou incomuns (OpenSolaris, mipsel etc.). Ver a página jbigi para instruções sobre diagnósticos, compilação e metodologias de testes.
If your native jbigi library is working fine, the biggest user of CPU may be routing traffic for participating tunnels. This uses CPU because at each hop a layer of encryption must be decoded. You can limit participating traffic in two ways - by reducing the share bandwidth on the confignet page, or by setting router.maxParticipatingTunnels=nnn on the configadvanced page.
If your router has 10 or more active peers, everything is fine. The router should maintain connections to a few peers at all times. The best way to stay "better-connected" to the network is to share more bandwidth. The amount of bandwidth that is shared by the router can be changed on the configuration page: http://localhost:7657/config
No, there isn't anything wrong. This is normal behavior. All routers adjust dynamically to changing network conditions and demands. Routers come online and go offline depending on whether the system it is installed on is operational or not, as well as whether there is an available network connection. Your router is constantly updating its local Network Database. Tunnels which your router is participating in expire every 10 minutes and may or may not be rebuilt through your router.
The encryption and routing within the I2P network adds a substantial amount of overhead and limits bandwidth. We can try to clarify this with the aid of a diagram:
In this diagram, the path that some I2P traffic takes as it travels through the network is traced. A user's I2P router is denoted by the box labeled 'A' and an I2P Hidden Service (for example, the http://stats.i2p website) is labelled as 'B'. Both the client and the server are using 3-hop tunnels, these hops are represented by the boxes labelled 'P', 'Q', 'R', 'X', 'Y', 'Z', 'P_1', 'Q_1', 'R'_1, 'X_1', 'Y_1' and 'Z_1'.
The boxes labelled 'P', 'Q' and 'R' represent an outbound tunnel for A while the boxes labelled 'X_1', 'Y_1', 'Z_1' represent an outbound tunnel for 'B'. Similarly, the boxes labelled 'X', 'Y' and 'Z' represent and inbound tunnel for 'B' while the boxes labelled 'P_1', 'Q_1' and 'R_1' represent an inbound tunnel for 'A'. The arrows in between the boxes show the direction of traffic. The text above and below the arrows detail some example bandwidth between a pair of hops as well as example latencies.
When both client and server are using 3-hop tunnels throughout, a total of 12 other I2P routers are involved in relaying traffic. 6 peers relay traffic from the client to the server which is split into a 3-hop outbound tunnel from 'A' ('P', 'Q', 'R') and a 3-hop inbound tunnel to 'B' ('X', 'Y', 'Z'). Similarly, 6 peers relay traffic from the server to back to the client.
First, we can consider latency - the time that it takes for a request from a client to traverse the I2P network, reach the the server and traverse back to the client. Adding up all latencies we see that:
40 + 100 + 20 + 60 + 80 + 10 + 30 ms (client to server) + 60 + 40 + 80 + 60 + 100 + 20 + 40 ms (server to client) ----------------------------------- TOTAL: 740 ms
The total round-trip time in our example adds up to 740 ms - certainly much higher than what one would normally see while browsing regular internet websites.
Second, we can consider available bandwidth. This is determined through the slowest link between hops from the client and server as well as when traffic is being transmitted by the server to the client. For traffic going from the client to the server, we see that the available bandwidth in our example between hops 'R' & 'X' as well as hops 'X' & 'Y' is 32 KB/s. Despite higher available bandwidth between the other hops, these hops will act as a bottleneck and will limit the maximum available bandwidth for traffic from 'A' to 'B' at 32 KB/s. Similarly, tracing the path from server to client shows that there is maximum bandwidth of 64 KB/s - between hops 'Z_1' & 'Y_1, 'Y_1' & 'X_1' and 'Q_1' & 'P_1'.
We recommend increasing your bandwidth limits. This helps the network by increasing the amount of available bandwidth which will in turn improve your I2P experience. Bandwidth settings are located on the http://localhost:7657/config page. Please be aware of your internet connection's limits as determined by your ISP, and adjust your settings accordingly.
We also recommend setting a sufficient amount of shared bandwidth - this allows for participating tunnels to be routed through your I2P router. Allowing participating traffic keeps your router well-integrated in the network and improves your transfer speeds.
I2P é um trabalho em progresso. Muitas melhorias e correções estão sendo implementadas, e, de maneira geral, usar o último lançamento vai auxiliar no seu desempenho. Se você não tem, instale o último lançamento.
You may report any bugs/issues that you encounter on our bugtracker, which is available over both non-private internet and I2P. We have a discussion forum, also available on I2P and non-private internet. You can join our IRC channel as well: either through our IRC network, IRC2P, or on Freenode.
- Nosso Rastreador De Falhas:
- Nossos fóruns: i2pforum.net
- Junte-se ao #i2p-dev Discuta com os desenvolvedores no IRC
Please include relevant information from the router logs page which is available at: http://127.0.0.1:7657/logs. We request that you share all of the text under the 'I2P Version and Running Environment' section as well as any errors or warnings displayed in the various logs displayed on the page.
Ótimo! Encontre-nos no IRC:
- no canal
- no canal