RN
2.3.0-7 available for easy testing deployment at I2Peek-a-Boo.i2p
orignal
zzz, it looks like we have scalability issue
orignal
I have 16K router on a floodfill
orignal
and since it's floodfill I can't cleanup more agressively then 1 hour expriration
orignal
what is the network grows more?
zzz
as long of the ratio of ff:non-ff stays the same, it won't make a difference
orignal
16K/1.5K
orignal
no it's not
orignal
basicallly number of non-FF grow more
orignal
it consumes resources
zzz
we discussed this and did a lot of work back in the attack days early this year
orignal
say we have the networks 5x more tommorow. what are we goping to do?
orignal
it's not about attack now
orignal
they seem real routers
zzz
right, the changes are still helping us
orignal
how many routers you have on a FF?
zzz
if you're ff, you can expire routers that aren't close-to-your-key faster than 1 hour. That's what we do now
zzz
I'm not running a ff now
orignal
hmm, interesting
orignal
didn't know that you even CAN expire faster
zzz
it's not ideal, but if the RI isn't in your keyspace then you really don't need to keep it
orignal
good point
orignal
will try to implement it
orignal
thanks
zzz
basically a probabalistic drop if older than 30 minutes if we're over 4000 routers
zzz
like this:
zzz
private static final int LIMIT_ROUTERS = SystemVersion.isSlow() ? 1000 : 4000;
zzz
long cutoff = now - 30*60*1000;
zzz
boolean isFF = _facade.floodfillEnabled();
zzz
byte[] ourRKey = isFF ? us.getData() : null;
zzz
// chance in 128
zzz
int pdrop = Math.max(10, Math.min(80, (128 * count / LIMIT_ROUTERS) - 128));
zzz
int removed = 0;
zzz
if (_log.shouldLog(Log.INFO))
zzz
_log.info("Expiring routers, count = " + count + " drop probability " +
zzz
(count > LIMIT_ROUTERS ? pdrop * 100 / 128 : 0) + '%');
orignal
probabalistic or based on DHT?
zzz
foreach router {
zzz
if (e.getDate() < cutoff) {
zzz
if (isFF) {
zzz
// don't drop very close to us
zzz
byte[] rkey = gen.getRoutingKey(key).getData();
zzz
int distance = (((rkey[0] ^ ourRKey[0]) & 0xff) << 8) |
zzz
((rkey[1] ^ ourRKey[1]) & 0xff);
zzz
// they have to be within 1/256 of the keyspace
zzz
if (distance < 256)
zzz
continue;
zzz
if (almostMidnight) {
zzz
// almost midnight, recheck with tomorrow's keys
zzz
rkey = gen.getNextRoutingKey(key).getData();
zzz
distance = (((rkey[0] ^ ourRKey[0]) & 0xff) << 8) |
zzz
((rkey[1] ^ ourRKey[1]) & 0xff);
zzz
if (distance < 256)
zzz
continue;
zzz
}
zzz
}
zzz
if (getContext().random().nextInt(128) < pdrop) {
zzz
_facade.dropAfterLookupFailed(key);
zzz
removed++;
orignal
great
zzz
}
zzz
so if they're within 1/256 of our routing key, we let them stay until 1 hour; otherwise we do a probabalistic drop if older than 30 minutes
orignal
so absolute minimum is 30 minutes now
zzz
yeah that's what we have now
orignal
the problem I see you will build tunnel through close to your only
zzz
I did this on Feb. 11, haven't really looked at it much since
zzz
nah because the pdrop is pretty low, it doesn't keep it at 4000; more like 8000-10000 max, iirc
orignal
then you have the same problem
orignal
if the network grows you will see much more routers in the netdb
zzz
sure, it's just one part of the defenses. But most of the routers in any ff are just ones that connected to you. They're not in your keyspace
zzz
16K / 1.5K = 10:1 x 4 redundancy from flooding is only 40 routers per ff in your keyspace
zzz
I;m sure the code above could be tweaked, you could change the 30 minutes, change the 1/256 number, change the probabilities and the threshold, etc
zzz
but thats the idea
orignal
I mean 30 minutes if not a final value
orignal
it should depend on total number of routers
orignal
say if you have 50K it might be reduced to 15 minutes
zzz
sure
zzz
iirc even during the attack, when i2pds were seeing 50K RIs, most java ffs were < 10K with this change
zzz
but everything can be tweaked
orignal
fake routers is another problem
zzz
it was good enough for us in February
zzz
but if you have 16K RIs and only 40 are in your keyspace, you can gain a lot by expiring the others faster
orignal
I know