orignal
gents, Vort has an idea
orignal
why don't we count only active transit tunnels, e.g. where at least 1 byte went through?
dr|z3d
we're still spending resources being in an inactive tunnel, orignal, or you're suggesting we *also* count active transits?
dr|z3d
we could show total/active if that's what you're suggesting, and timeout participating tunnels that don't have any traffic after x seconds, perhaps. iirc, canon doesn't display inactive participating tunnels on their tunnels page.
orignal
yes, and apply limits to active tunnels only
orignal
why do you think they consume resource?
orignal
just record in hash table and layer encryption key
orignal
the point is if you have limit of 1000 transit tunnels, but you have 10000 whene 9000 are incative
orignal
if an atacker try to flood with tunnel, inactive tunnels wouldn't count
dr|z3d
orignal: if an attacker's creating tunnels that aren't sending data, we should watch for that and just drop the tunnel after x seconds of inactivity.
dr|z3d
what's reasonable? 2 minutes?
dr|z3d
the issue is that there may be false positives.
dr|z3d
not sure that's much of an issue, however. inactive tunnels can easily get rebuilt.
not_bob
I seem to generate tunnels that don't get used much sometimes.
orignal
no, it's woong
orignal
destinations usually create backup tunnels that stay inactive for 8 minutes for exampple
orignal
and become active when main one is being replaced
zzz
you can count your tunnels and otherwise manage/limit your resources (memory, bandwidth, etc.) however you want
zzz
but once you accept a tunnel that's an 11-minute commitment, you can't change your mind 2 minutes later
orignal
Transit Tunnels: 71706
orignal
zzz, how much resources does an inactive tunnel consume?
orignal
zzz, that's what I mean if I accept I don't drop for 11 minutes. But I don't conunt for limits
zzz
not much
zzz
but not zero
zzz
that's fine. you can manage your limits however you want
orignal
<onon1> А уменя позавчера 230к
orignal
230K transit tunnels
orignal
his limit is 1M