~dr|z3d
@RN
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@zzz
%Liorar
+Gid_
+RTP
+Unbur
+cumlord
+profetikla
+uop23ip
+weko
An0nm0n
Arch
DeltaOreo
FreefallHeavens
Hidenet1
Irc2PGuest2827392
Irc2PGuest33877
Irc2PGuest38326
Irc2PGuest68850
Irc2PGuest68893
Irc2PGuest70866
Leopold
Nausicaa
Onn4l7h
Onn4|7h
ProRu
StormyCloudInc
Titlacahuan__
acetone_
admin
anon1
anon2
anu
cheddah
itsjustme
j6
limak
not_bob_afk
poriori
qend-irc2p
Anomaly
hi everyone
dr|z3d
what up Anomaly
Anomaly
howve you been dr|z3d
Anomaly
i got sushi :)
dr|z3d
not bad, thanks, Anomaly. enjoy1
Anomaly
thanks
dr|z3d
you good?
Anomaly
yea ive been good, im about to help a friend with luggage, and then ill be back
mesh
dr|z3d: does i2p+ have an issue tracker?
dr|z3d
that's for issues that are i2p+ specific. for general i2p issues, use i2p's issue tracker.
mesh
dr|z3d: is there any concern that peerTestTimeout might lead to a situation where there's too few candidates?
dr|z3d
mesh: no
dr|z3d
if you set it lower than the average successful timeout, it'll auto-adjust to that value.
mesh
dr|z3d: it's interesting that the avg is taken. I would think you might want the median, to include at least the top half
dr|z3d
PeerTestJob.java is what you want to look at if you want to test variations on the current implementation, mesh.
mesh
dr|z3d: it's an interesting research problem. you ought to write something up.
dr|z3d
No, mesh, YOU ought to write something up :)
dr|z3d
I'm still looking forward to "Excursions into the I2P/I2P+ codebase" blog with your name on it :)
mesh
Maybe some efforts can be made into making the algorithm configurable. What I was actually thinking is you want three numbers: (1) a PeerTestTarget (2) the maximum "use count" for a peer within a given period (you don't want to use the same peer too many times in too many tunnels) and (3) a random variance to make the algorithm deliberately non-deterministic
dr|z3d
1 and 2 are already implemented. not sure how you'd go about 3.
GalaxyNova
is it possible to create a tunnel to a website like wikipedia
mesh
dr|z3d: 3 would be a rule that says "I want to build a tunnel consisting of 3 peers. Find me three peers with the lowest "use count" whose PeerTestAvg is <= PeerTestTarget + $RandoNumber"
GalaxyNova
or does it have to be local addresses
dr|z3d
GalaxyNova: you can do it with an ip address. that's fairly simple, assuming you have the ip address.
dr|z3d
mesh: 3 is kind of taken care of by 2, but doubtless there's room for improvement.
dr|z3d
GalaxyNova: for clearnet addresses, it's possible, though https is more complicated than http.
mesh
dr|z3d: the idea being that you might be okay exceeding the PeerTestTarget if you are concerned about an attacker flooding your candidate pool with very fast nodes (PeerTest < 500) that are all controlled by the attacker
dr|z3d
mesh: that's why I2P+ allows for a much larger pool of fast/high cap peers.
dr|z3d
not so many as to dilute the performance, not too few that it makes it easy for an attack to pollute.
dr|z3d
GalaxyNova: if you're hosting the service yourself, you can run it on a different box and point the tunnel to the ip.. easy to multihome to a dynamic (read db-driven) server that way.
dr|z3d
mesh: also, if any peer in the tunnels is already being used for x percentage, and you've run out of fast peers, you won't reuse existing fast peers and exceed their budget. you'll drop down to the next tier.
mesh
dr|z3d: yeah that would work too. what you really want it something like a weighting system. PeerTestTime < PeerTestTarget might give you +10, Uptime might give you another +5, but too much use weight might give you -25. You might keep an eye out for geographic homogenity and other factors too.
dr|z3d
> router.maxTunnelPercentage
mesh
like I said it's an interesting problem you should write something about it heh
mesh
dr|z3d: is that percentage as in "percentage of data sent/received" or percent of tunnels used in the last hour?
dr|z3d
I2P+ already goes the extra distance wrt homogenity. no peer in the same /4 can be used in a single local tunnel iirc.
dr|z3d
router.maxTunnelPercentage={n}
dr|z3d
Defines the maximum percentage of active local tunnels (client and exploratory) that a peer will be used for. [Default is 25%]
mesh
actually if the code really is pluggable I would be more interested in building a "trusted overlay."
dr|z3d
/ private static final int DEFAULT_MAX_PCT_TUNNELS = 33;
dr|z3d
private static final int DEFAULT_MAX_PCT_TUNNELS = 15;
mesh
In other words only build tunnels through routers that I control
dr|z3d
so help needs updating.
mesh
ah interesting
dr|z3d
the groundwork has already been laid for trusted tunnel builds.
mesh
dr|z3d: in I2P or I2P+?
dr|z3d
both
mesh
you have a link where I could read about it?
dr|z3d
no
dr|z3d
it's not yet active, at least not in i2p/i2p+. but some prep work has been done.
dr|z3d
git grep "restricted routes"
mesh
dr|z3d: if it's what I'm thinking it could be a very valuable service. at least in theory you could build secure, multi-hop, but very fast vpns on top of i2p
mesh
either restrict tunnels only to the very fast nodes provides by a vpn, or even allow tunnels that include 1 random hop and then 2 fast vpn nodes
dr|z3d
git grep explicitPeers
dr|z3d
and mesh, you really should be pulling down the latest i2p+ code regularly and building yourself updates.. would be good to get someone else looking over the changes as they happen.
dr|z3d
building an update usually takes less than a minute the first time, and usually around 15s or less thereafter, unless you're rebuilding all the code again after an ant distclean.