Both i2p-projekt.i2p and echelon.i2p are always the most responsive eepsites for me to visit. How are they able to achieve this? Good router integration is assumed, but that can't be the only reason.
Are they just hosted from a great data center near a big backbone pushing X class bandwidth? Are they simply reducing the number of inbound and outbound tunnels server-side to 1 or even 0? Are they multihomed? Is there a perfect balance of overall bandwidth and shared bandwidth (for transit tunnels) that I just don't know about? Excuse me for this walking speculation, but I'm genuinely interested in tips for improving the performance of eepsites without reducing anonymity (much).
Fast eepsites! How?!!
Re: Fast eepsites! How?!!
Hi
Ii is simple: just have a reachable I2P router, have it multihomed and set in/out tunnels to only 1 hop, as the clearnet servers are already known. No need to add seperate additional layers.
No need to fancy hardware or bandwidth above default DSL lines.
echelon
Ii is simple: just have a reachable I2P router, have it multihomed and set in/out tunnels to only 1 hop, as the clearnet servers are already known. No need to add seperate additional layers.
No need to fancy hardware or bandwidth above default DSL lines.
echelon
Re: Fast eepsites! How?!!
Useful to know—thank you. But how do you multihome a single router? I understood multihoming as using the same destination keys on several routers.
Also, I assume a serverside tunnel uses the router's non-shared bandwidth (like any normal client application) plus whatever is available from the shared slice for mix traffic, right? So a router tuned for server responsiveness would need to ensure there was enough available bandwidth for expected use while not setting the shared traffic slice so low to compromise the integration and cover of the mix traffic. Am I on the right track?
Also, I assume a serverside tunnel uses the router's non-shared bandwidth (like any normal client application) plus whatever is available from the shared slice for mix traffic, right? So a router tuned for server responsiveness would need to ensure there was enough available bandwidth for expected use while not setting the shared traffic slice so low to compromise the integration and cover of the mix traffic. Am I on the right track?
Re: Fast eepsites! How?!!
You do not multihome on a single router. You may increase number of tunnels to do that job.aegypius wrote: ↑04 Jun 2020 18:25 Useful to know—thank you. But how do you multihome a single router? I understood multihoming as using the same destination keys on several routers.
Also, I assume a serverside tunnel uses the router's non-shared bandwidth (like any normal client application) plus whatever is available from the shared slice for mix traffic, right? So a router tuned for server responsiveness would need to ensure there was enough available bandwidth for expected use while not setting the shared traffic slice so low to compromise the integration and cover of the mix traffic. Am I on the right track?
Own services (client tunnel) are always preferred over participating tunnels, up to 0 participating traffic. Even with 100% share setting, own services (client tunnels) do get the bandwidth preferred.
echelon
Re: Fast eepsites! How?!!
For a hidden service, does it ever make sense to increase the number of outbound tunnels but not inbound tunnels? (Or vice-versa?) I appreciate but remain puzzled by some of the granularity the router software gives you.
Re: Fast eepsites! How?!!
Hi
depends on the kind of use pattern.
More tunnels = more possible connections.
is usecase is less clients reaching a service, but service distributes to lots of clients, setup is less IN tunnels, more out.
depends on the kind of use pattern.
More tunnels = more possible connections.
is usecase is less clients reaching a service, but service distributes to lots of clients, setup is less IN tunnels, more out.
Re: Fast eepsites! How?!!
I was able to significantly improve the performance of my eepsite because of your help. Thank you!