zzz.i2p

Development discussions
[experimental patch] - Round robin tunnel selection - promising results « Big Topics, Ideas, Proposals and Discussion « I2P Development
 
Mon, 20 Nov 2017, 08:21pm #1
zab
I2P Legend

Hi,

Someone gave me an idea and I put together the following patch http://zerobin.i2p/?4cd6d823551e6c00#vPGVgVMI5o...=

Initial results are very encouraging, and the traffic distribution as reported at /tunnels is more even than with the current random approach.

IMPORTANT: I have not analyzed the privacy/anonymity implications of this. A very powerful and smart adversary might be able to pick you out if you are running this patch.

Give it a go, let me know the results!

Z


email: zab@mail.i2p Irc2P/keybase: zlatinb
blog: http://zab.i2p
MuWire: http://muwire.i2p
MuCats: http://mucats.i2p
MuWire nickname: zlatinb@3k2gijdfdcuczkfypfddj4qsnnf744mj

Wed, 22 Nov 2017, 10:40pm #2
mrbamboo
I2P Legend

This works great.
Finally the tunnel pool gets fully utilized.
It operates on the destination level - meaning that traffic like bittorrent or multiple sources of an http website or a multisource download gets boosted significantly.
Be aware that your router might hit cpu and traffic limits - for me this is a good thing.
I would love to hear comments of other devs on this - I personally think that it is not affecting anonymity.

Cheerz ;-)


blog:
http://mrbamboo.i2p/

tracker: http://ektvjazypk6ibcv4lxivzz5twsj6mfrdfbl7cs2k...

bote:
6g8uD-faTp4wXuobi6Td~~EBtpkm2oxIIVdmKXDuGwdn4XbniUHz1JqUQcudkc4LkP4tjDuFvTBR721gVNLnvr

Thu, 23 Nov 2017, 04:18am #3
mrbamboo
I2P Legend

From what I can tell i2psnark UNFORTUNATELY handels destination tunnels differntly.
It seems that it has a fixed 1 tunnel per single torrent mappping.
Is there a reason for that ?
Maybe a dev can shed some light on this issue.

Cheerz ;-)


blog:
http://mrbamboo.i2p/

tracker: http://ektvjazypk6ibcv4lxivzz5twsj6mfrdfbl7cs2k...

bote:
6g8uD-faTp4wXuobi6Td~~EBtpkm2oxIIVdmKXDuGwdn4XbniUHz1JqUQcudkc4LkP4tjDuFvTBR721gVNLnvr

Thu, 23 Nov 2017, 01:29pm #4
zzz
Administrator
Zzz

Caching.

As we both have said repeatedly, this is a bad idea. Just because it's now coded as a patch doesn't make a difference.

You're asking for a lot of developer time for changes to code, packaging, and architecture on a 14-year-old well-documented code base. That's very inefficient because we don't understand your reasons or your application - we haven't seen anything. Your best path is to get your app working, put up your code and your docs, get some testing and some users. If you absolutely need changes to i2p, implement those changes yourself, carry them locally, and once everything's working great, you can make your case on why it's important and why it's the right way to do it. You can do that for small changes via trac, or for large changes via our Proposal process.

Until all that happens, the best use of our time is to help you use our interfaces, libraries, and protocols - without changes - in the most efficient, effective, and well-designed manner.

Thu, 23 Nov 2017, 03:14pm #5
mrbamboo
I2P Legend

Understood,

I appreciate the effort !

Cheerz ;-)

zzz wrote:

Caching.

As we both have said repeatedly, this is a bad idea. Just because it's now coded as a patch doesn't make a difference.

You're asking for a lot of developer time for changes to code, packaging, and architecture on a 14-year-old well-documented code base. That's very inefficient because we don't understand your reasons or your application - we haven't seen anything. Your best path is to get your app working, put up your code and your docs, get some testing and some users. If you absolutely need changes to i2p, implement those changes yourself, carry them locally, and once everything's working great, you can make your case on why it's important and why it's the right way to do it. You can do that for small changes via trac, or for large changes via our Proposal process.

Until all that happens, the best use of our time is to help you use our interfaces, libraries, and protocols - without changes - in the most efficient, effective, and well-designed manner.


blog:
http://mrbamboo.i2p/

tracker: http://ektvjazypk6ibcv4lxivzz5twsj6mfrdfbl7cs2k...

bote:
6g8uD-faTp4wXuobi6Td~~EBtpkm2oxIIVdmKXDuGwdn4XbniUHz1JqUQcudkc4LkP4tjDuFvTBR721gVNLnvr

Mon, 27 Nov 2017, 12:59pm #6
YesYesYes well maybe
I2P Legend

I wish you would explain this a little more. How does having a Round Robin scheme fill the tunnels??? It already does that, doesn't it. Swapping tunnels every so often. Are you swapping them it faster? More tunnels? It does sound interesting that you're getting better traffic.

Mon, 27 Nov 2017, 05:56pm #7
mrbamboo
I2P Legend

Currently a tunnel is selected randomly out of the pool to connect you to a .b32.i2p destination.
Eventually ( after many different .b32.i2p destinations ) every tunnel of the pool gets hit.
But in practice 50% of the tunnels are just sitting around doing nothing.
So zlatinb changed the algorithm so that every new .b32.i2p is connect with the next tunnel in line.
All tunnels are utilized evenly as soone as you have connected to enough destinations ( say 3 tunnels in a pool and 3 or more destinations ) and that get's you more download speed on i2psnark or when you surfe multiple eepsites or whatever application has more than 1 tunnel ( this does not apply to irc as it has only one destination .b32.i2p all the time).

As I wrote on my blog - give it a try if you can.

Cheerz ;-)


blog:
http://mrbamboo.i2p/

tracker: http://ektvjazypk6ibcv4lxivzz5twsj6mfrdfbl7cs2k...

bote:
6g8uD-faTp4wXuobi6Td~~EBtpkm2oxIIVdmKXDuGwdn4XbniUHz1JqUQcudkc4LkP4tjDuFvTBR721gVNLnvr

Sat, 02 Dec 2017, 01:30pm #8
YesYesYes well maybe
I2P Legend

@mrbamboo OK thanks I get it. I don't see how it would hurt anonymity. I also don't see how it could speed things up. Maybe all the tunnels are not used evenly but all that you are using, well you're using them that you have set up to use. The ones sitting and not being used have no bearing on how many you are using in the first place. Now I guess spreading the load more evenly could possibly speed things up but the "quality" of each tunnel is different so I could see a scenario where using all of them would slow things down.

Sat, 02 Dec 2017, 01:50pm #9
mrbamboo
I2P Legend

Aboslutely right,

and yes I realized that bevore proposing this patch, but I arrived at this by observing the tunnels of a LS.
As everything in I2P is more ore less stochastic in nature you argument sounds good.
BUT when you run torrents or surf various eepsites the effect is more than noticeable.
I did some extensive testing with zlatinb's RR patch with a custom multisource downloader.
The speed increase is substantial and roughly proportonial to the tunnel pool utilization.

Cheerz ;-)

YesYesYes well maybe wrote:

@mrbamboo OK thanks I get it. I don't see how it would hurt anonymity. I also don't see how it could speed things up. Maybe all the tunnels are not used evenly but all that you are using, well you're using them that you have set up to use. The ones sitting and not being used have no bearing on how many you are using in the first place. Now I guess spreading the load more evenly could possibly speed things up but the "quality" of each tunnel is different so I could see a scenario where using all of them would slow things down.


blog:
http://mrbamboo.i2p/

tracker: http://ektvjazypk6ibcv4lxivzz5twsj6mfrdfbl7cs2k...

bote:
6g8uD-faTp4wXuobi6Td~~EBtpkm2oxIIVdmKXDuGwdn4XbniUHz1JqUQcudkc4LkP4tjDuFvTBR721gVNLnvr

Sun, 03 Dec 2017, 05:06am #10
YesYesYes well maybe
I2P Legend

@mrbamboo OK thanks I get it. I don't see how it would hurt anonymity. I also don't see how it could speed things up. Maybe all the tunnels are not used evenly but all that you are using, well you're using them that you have set up to use. The ones sitting and not being used have no bearing on how many you are using in the first place. Now I guess spreading the load more evenly could possibly speed things up but the "quality" of each tunnel is different so I could see a scenario where using all of them would slow things down.

Sun, 03 Dec 2017, 05:08am #11
YesYesYes well maybe
I2P Legend

My apologies for posting so many times but when I posted I got a message that it didn't post from the forum?????

Sun, 03 Dec 2017, 05:16am #12
YesYesYes well maybe
I2P Legend

I'm not saying you're wrong just so we understand. I'm just curious and reasoning out possibilities. If it sounds like criticism it's not.

You used the word ,"stochastic", meaning, "an adjective in English that describes something that was randomly determined". Ok, but you're not reducing randomness. You're only making a list of all tunnels available and running them in order. I'm assuming that the list itself is randomly picked from a poll from whereever. I wonder if you use a tunnel and if it is reused within a certain time limit there's a penalty so that each server that passes data along the tunnel from source to destination and back does NOT get overloaded. That would account for the speed up????

Sun, 03 Dec 2017, 05:18am #13
YesYesYes well maybe
I2P Legend

"...I arrived at this by observing the tunnels of a LS"

What's an "LS"?

Sun, 03 Dec 2017, 09:54am #14
mrbamboo
I2P Legend

Before we get lost in conceptual and grammatic issues...

Try running i2psnark with only one tunnel and download a popular torrent.
Then checkout the :7657/tunnels page and look for i2psnark - there you will find the Lease Set of tunnels i2psnark is using.
How fast is i2pnark with one tunnel ?
Now try running i2psnark with 5 tunnels and repeat above procedure.
What do you see now - how fast is i2psnark now - how many tunnels show elevated traffic?

Read http://echelon.i2p/i2p/i2pspeed.txt
If you get it, you get it... ( no offence ).


blog:
http://mrbamboo.i2p/

tracker: http://ektvjazypk6ibcv4lxivzz5twsj6mfrdfbl7cs2k...

bote:
6g8uD-faTp4wXuobi6Td~~EBtpkm2oxIIVdmKXDuGwdn4XbniUHz1JqUQcudkc4LkP4tjDuFvTBR721gVNLnvr

Sun, 03 Dec 2017, 02:23pm #15
YesYesYes well maybe
I2P Legend

Thanks for your patience and answering my questions.

LS, Lease Set

cough, cough turns red. I knew this. Brain fart.

Ok I read the document. I'm assuming when he says,

"...And because every I2P node has different tunnels built, no two I2P nodes have the same tunnel sets..."

tunnels sets = Lease set

I think I see where the speed up is in the patch. He says,

"...it is quite expensive in CPU time to build a tunnel. This is
why a destination is only allowed to have a max of 6 IN and 6 OUT tunnels to transport data.

...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..."

I bet that explains it. By running ALL tunnels sequentially you make sure that it's less likely to use over "6 in 6 out" by using the same nodes over and over to make tunnels.

The question is, is there a function, or quirk, that predisposes I2P to us the same nodes over and over when it's supposed to be random? I know it picks the better, faster nodes for tunnels. Maybe as one is released it gets picked up again, because it was good. What determines from the nodes perspective that a client is demanding too much or is using it's node too much and does it throttle down that client? Could there be a problem there? I would call it a bug.

Sun, 03 Dec 2017, 02:50pm #16
mrbamboo
I2P Legend

Hey,

actually it's not about the same nodes but rather not using all available tunnels in a pool ( Lease Set ).

On a side note - using the same nodes is a consequence of a low number of fast peers.

Take a look at the vanilla code:

https://github.com/i2p/i2p.i2p/blob/master/rout...

and then the patched version:

http://fossil.z-lab.i2p/artifact/2e06830468b488c0

The difference is that the later one at least uses all tunnels per se.

In a scenario with multiple destinations ( = possibly different tunnels vanilla - all tunnels RR patch ) you spread the load. Off course you cannot influnence the individual tunnel speed - BUT asuming that NOT ALL tunnels are slow at the same time - you end up with greater download speeds in average without chaning the i2p logic itself.
The last piece of a torrent needs to finish in order to have the whole transfer completed - but instead of wasting time on a few tunnels we go for ALL of them.

Give it a try with 1 / 3 / 5 tunnels in snark and the RR patch.
Also notice that surfing different eepsites you will notice that the tunnels get trigger on different destinations.

All I'm saying is - why leave so many tunnels in a pool dormant ?
You do the math ;-) !

Thanks for keeping up and I sincerely hope you can follow the logic behind the RR patch of zlatinb.

Cheerz ;-)

YesYesYes well maybe wrote:

Thanks for your patience and answering my questions.

LS, Lease Set

cough, cough turns red. I knew this. Brain fart.

Ok I read the document. I'm assuming when he says,

"...And because every I2P node has different tunnels built, no two I2P nodes have the same tunnel sets..."

tunnels sets = Lease set

I think I see where the speed up is in the patch. He says,

"...it is quite expensive in CPU time to build a tunnel. This is
why a destination is only allowed to have a max of 6 IN and 6 OUT tunnels to transport data.

...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..."

I bet that explains it. By running ALL tunnels sequentially you make sure that it's less likely to use over "6 in 6 out" by using the same nodes over and over to make tunnels.

The question is, is there a function, or quirk, that predisposes I2P to us the same nodes over and over when it's supposed to be random? I know it picks the better, faster nodes for tunnels. Maybe as one is released it gets picked up again, because it was good. What determines from the nodes perspective that a client is demanding too much or is using it's node too much and does it throttle down that client? Could there be a problem there? I would call it a bug.


blog:
http://mrbamboo.i2p/

tracker: http://ektvjazypk6ibcv4lxivzz5twsj6mfrdfbl7cs2k...

bote:
6g8uD-faTp4wXuobi6Td~~EBtpkm2oxIIVdmKXDuGwdn4XbniUHz1JqUQcudkc4LkP4tjDuFvTBR721gVNLnvr

Sun, 03 Dec 2017, 03:03pm #17
mrbamboo
I2P Legend

Check the https://geti2p.net/el/docs/tunnels/implementation section Tunnel Pools

.... the router selects one out of the appropriate pool at random.

That is the whole point I'm referring to. For what reason should we pick one at random ?

Maybe one the of the java i2p dev's can answer that - original had a baffeling statement about this on PurpleI2P i2pd tunnel pool seelction:

https://github.com/PurpleI2P/i2pd/issues/1015

Just to select random "good" tunnel, assuming that more than half are good.

Cheerz ;-)


blog:
http://mrbamboo.i2p/

tracker: http://ektvjazypk6ibcv4lxivzz5twsj6mfrdfbl7cs2k...

bote:
6g8uD-faTp4wXuobi6Td~~EBtpkm2oxIIVdmKXDuGwdn4XbniUHz1JqUQcudkc4LkP4tjDuFvTBR721gVNLnvr

Sun, 03 Dec 2017, 04:44pm #18
zab
I2P Legend

is there a function, or quirk, that predisposes I2P to us the same nodes over and over when it's supposed to be random

There is a "stickiness" property to the tunnel selection logic - within a 500ms interval only a single tunnel from a pool will be selected, no matter how many are available. This patch removes that property.


email: zab@mail.i2p Irc2P/keybase: zlatinb
blog: http://zab.i2p
MuWire: http://muwire.i2p
MuCats: http://mucats.i2p
MuWire nickname: zlatinb@3k2gijdfdcuczkfypfddj4qsnnf744mj

Mon, 04 Dec 2017, 07:58am #19
YesYesYes well maybe
I2P Legend

I thought I had it but you're confusing me by changing definitions frequently. My understanding is tunnels are being built all the time. Obviously each tunnel is a set of nodes that are hopped through depending on how many nodes you have set to use. Now the normal situation is that new tunnels will be selected from the lease Set of tunnels that has been continuously built up.

zab,"only a single tunnel from a pool will be selected, no matter how many are available. This patch removes that property..."

mrbamboo,"...and but instead of wasting time on a few tunnels we go for ALL of them..."

"...Give it a try with 1 / 3 / 5 tunnels in snark and the RR patch..."

I fully understand that raising the number of tunnels used will obviously raise you're data throughput as long as your computer system can handle it. I do this myself.

Here's where I'm having trouble exactly. First mrbamboo said that the patch used a round robin technique to "select" new tunnels and made sure that "every" single tunnel had a chance to participate if they were a part of the pool/lease set. Ok I get that but it confused me on how "with a limited number of tunnels" being used a one time, no matter how they're selected, I don't see how you could get big increase in throughput. Let's say you have 5 tunnels for I2PSnark coming in then you can only use 5 tunnels coming in no matter were they come from. I could see a little increase from utilizing all the tunnels in some order but not a lot.

Now mrbamboo is saying, if I understand correctly,"...but instead of wasting time on a few tunnels we go for ALL of them..."

This seems to me to defeat the whole purpose of having a "number of tunnels" selection in the first place because it will just use as many as are in the pool. Why couldn't a person just crank up the number of tunnels instead of patching anything??? I see the point in using all the tunnels in the pool in order but NOT hard-wiring that they ALL be used all the time.

Mon, 04 Dec 2017, 09:09am #20
mrbamboo
I2P Legend

Say you have a 5 tunnel setting for i2psnark and you are downloading a torrent with 5 destinations.

The vanilla i2p router does NOT distribute those 5 destinations to the 5 tunnels at best it takes 3 of them due to 'random' selection and other criteria.

The one app that does hit all tunnels with the vanilla i2p is bote - it has many destinations no matter what ( between 100 and 200 at all times ).

Whe surfing eepsites ( and having say 3 tunnels for the http proxy ) the RR does have some effect.

The irc2ip app is not affected by this cause it's on one destination all the time.

So depending on the app you get more throughput - torrenting ( especially initial seeding ) and bote are the best candidates for hitting ALL tunnels ALL the time.

That's the whole point of the RR patch.

By running the scenario of an initial seed with 3 or more peers the difference to the vanilla i2p cleaerly sticks out.

About the terminology - sorry about that, i'll be more ubiquitos / consistent next time.

Cheerz ;-)

YesYesYes well maybe wrote:

I thought I had it but you're confusing me by changing definitions frequently. My understanding is tunnels are being built all the time. Obviously each tunnel is a set of nodes that are hopped through depending on how many nodes you have set to use. Now the normal situation is that new tunnels will be selected from the lease Set of tunnels that has been continuously built up.

zab,"only a single tunnel from a pool will be selected, no matter how many are available. This patch removes that property..."

mrbamboo,"...and but instead of wasting time on a few tunnels we go for ALL of them..."

"...Give it a try with 1 / 3 / 5 tunnels in snark and the RR patch..."

I fully understand that raising the number of tunnels used will obviously raise you're data throughput as long as your computer system can handle it. I do this myself.

Here's where I'm having trouble exactly. First mrbamboo said that the patch used a round robin technique to "select" new tunnels and made sure that "every" single tunnel had a chance to participate if they were a part of the pool/lease set. Ok I get that but it confused me on how "with a limited number of tunnels" being used a one time, no matter how they're selected, I don't see how you could get big increase in throughput. Let's say you have 5 tunnels for I2PSnark coming in then you can only use 5 tunnels coming in no matter were they come from. I could see a little increase from utilizing all the tunnels in some order but not a lot.

Now mrbamboo is saying, if I understand correctly,"...but instead of wasting time on a few tunnels we go for ALL of them..."

This seems to me to defeat the whole purpose of having a "number of tunnels" selection in the first place because it will just use as many as are in the pool. Why couldn't a person just crank up the number of tunnels instead of patching anything??? I see the point in using all the tunnels in the pool in order but NOT hard-wiring that they ALL be used all the time.


blog:
http://mrbamboo.i2p/

tracker: http://ektvjazypk6ibcv4lxivzz5twsj6mfrdfbl7cs2k...

bote:
6g8uD-faTp4wXuobi6Td~~EBtpkm2oxIIVdmKXDuGwdn4XbniUHz1JqUQcudkc4LkP4tjDuFvTBR721gVNLnvr

Tue, 05 Dec 2017, 05:14am #21
YesYesYes well maybe
I2P Legend

AHHH! Why it doesn't give you 3 tunnels, out of the pool of many, when you ask for 3 tunnels in the vanilla is a mystery to me. I could see a rapid speedup if you asked for 5 tunnels and got 5 instead of only 2 or 3.

Thanks for the explanation and the links. The docs for I2p are spread out and sometimes it's difficult to tell where to start looking for anything.

Is there documentation where I can replace just the part of I2P that has changed? I have my setup tweaked and I also don't want to over write all my changes in the several files that have to be changed. Could I just exchange one file?

Tue, 05 Dec 2017, 05:21am #22
YesYesYes well maybe
I2P Legend

I notice zlabs fossil system for tickets you have to use javascript. I refuse to use javascript for anything in I2P, and anywhere else if I can help it, and I bet others feel the same.

Tue, 05 Dec 2017, 07:32am #23
zab
I2P Legend

I notice zlabs fossil system for tickets you have to use javascript.

The exact message is "Please enable javascript or log in to see this content" (emphasis mine).

You can log in with an anonymous login if you do not want to create an account.


email: zab@mail.i2p Irc2P/keybase: zlatinb
blog: http://zab.i2p
MuWire: http://muwire.i2p
MuCats: http://mucats.i2p
MuWire nickname: zlatinb@3k2gijdfdcuczkfypfddj4qsnnf744mj

Tue, 05 Dec 2017, 07:45am #24
zab
I2P Legend

Why it doesn't give you 3 tunnels, out of the pool of many, when you ask for 3 tunnels in the vanilla is a mystery to me.

Mostly the "stickiness" property I described earlier. If you ask for 3 tunnels within 500ms interval you're going to get only 1.

Also, even without stickiness uniform random distribution does not produce equal utilization across the tunnels. That is because every tunnel has an equal chance of being selected, even if it has been selected on a previous attempt.


email: zab@mail.i2p Irc2P/keybase: zlatinb
blog: http://zab.i2p
MuWire: http://muwire.i2p
MuCats: http://mucats.i2p
MuWire nickname: zlatinb@3k2gijdfdcuczkfypfddj4qsnnf744mj

Tue, 05 Dec 2017, 01:17pm #25
0Aosas
Contributor

Well, I think we may change the settings in "i2ptunnelmgr" page.

Why don't we select different numbers for inbound and outbound tunnels? Like we had already done in I2PSnark.

For example, a user "just" wants to download torrents, so he can use 16 inbound tunnels and 3 outbound tunnels.

So in this way, bandwidth and CPU time can be saved.

Hope this can help!

----OAosas

Tue, 05 Dec 2017, 03:31pm #26
mrbamboo
I2P Legend

On spot - well done !

Cheerz ;-)

zab wrote:

Why it doesn't give you 3 tunnels, out of the pool of many, when you ask for 3 tunnels in the vanilla is a mystery to me.

Mostly the "stickiness" property I described earlier. If you ask for 3 tunnels within 500ms interval you're going to get only 1.

Also, even without stickiness uniform random distribution does not produce equal utilization across the tunnels. That is because every tunnel has an equal chance of being selected, even if it has been selected on a previous attempt.


blog:
http://mrbamboo.i2p/

tracker: http://ektvjazypk6ibcv4lxivzz5twsj6mfrdfbl7cs2k...

bote:
6g8uD-faTp4wXuobi6Td~~EBtpkm2oxIIVdmKXDuGwdn4XbniUHz1JqUQcudkc4LkP4tjDuFvTBR721gVNLnvr

Wed, 06 Dec 2017, 08:49am #27
YesYesYes well maybe
I2P Legend

"...Please enable javascript or log in to see this content" (emphasis mine).

You can log in with an anonymous login if you do not want to create an account..."

My apologies. I get it. I saw Javascript mentioned and...immediately stop reading and assume the worst.

Wed, 06 Dec 2017, 08:59am #28
YesYesYes well maybe
I2P Legend

zab wrote:

There is a "stickiness" property to the tunnel selection logic - within a 500ms interval only a single tunnel from a pool will be selected, no matter how many are available. This patch removes that property.

What's the purpose for this??? It it some kind of randomization system? Could you keep this, if there's a reason for it, but have a check to make sure that the amount of tunnels you request are actually present. So it needs three. Only gets one so it checks again in 500ms and if the number doesn't equal the requested number of tunnels that is set by the user then it gives you another...repeat.

The stickiness could be of some value. Does getting rid of it compromise anonymity in any way?

Thanks for all the work all you are doing. Much appreciated.

Wed, 06 Dec 2017, 06:33pm #29
mrbamboo
I2P Legend

Does the way the tunnel is selected or the stickiness provide the anonymity ?
I think not - the i2p tunnel building and operation itself provides the anonymity.
The stickiness for 500ms is probably better for low ressource routers so they don't consume a lot of tunnels and therefore cpu + bandwidth.
Might be a better idea to shrink the tunnel pool size if you have a low ressource router.
This indirectly makes the point on this topic from a different angle.
Why build tunnels that get not used at all ?

Cheerz ;-)

YesYesYes well maybe wrote:

zab wrote:

There is a "stickiness" property to the tunnel selection logic - within a 500ms interval only a single tunnel from a pool will be selected, no matter how many are available. This patch removes that property.

What's the purpose for this??? It it some kind of randomization system? Could you keep this, if there's a reason for it, but have a check to make sure that the amount of tunnels you request are actually present. So it needs three. Only gets one so it checks again in 500ms and if the number doesn't equal the requested number of tunnels that is set by the user then it gives you another...repeat.

The stickiness could be of some value. Does getting rid of it compromise anonymity in any way?

Thanks for all the work all you are doing. Much appreciated.


blog:
http://mrbamboo.i2p/

tracker: http://ektvjazypk6ibcv4lxivzz5twsj6mfrdfbl7cs2k...

bote:
6g8uD-faTp4wXuobi6Td~~EBtpkm2oxIIVdmKXDuGwdn4XbniUHz1JqUQcudkc4LkP4tjDuFvTBR721gVNLnvr

Thu, 07 Dec 2017, 02:03pm #30
0Aosas
Contributor

Maybe we can use different numbers of inbound and outbound tunnels in "i2ptunnelmgr" page's options.

This will use less network bandwidth or CPU time.