orignal
will check
orignal
it shouldn't
orignal
I conclude that number of tunnels/bandwidth is attack
orignal
btw it's possible that someone sets it manually
orignal
for example trusishka likes to use this config param
dr|z3d
if it's an attack, orignal, now's a good time to think about how to mitigate it.
dr|z3d
for example, it's unlikely that legitimate usage requires hosting 100s of transit tunnels for a single router over a short period, however many requests your router can handle.
dr|z3d
you can also think about limiting the number of requests made to a peer relative to the number of total transit tunnels you're hosting.
dr|z3d
or rather, for x transit tunnels, don't request more than y% from any given peer.
orignal
zzz, why do you always send floow-on fragment before first?
orignal
it produces some inefficency
orignal
I have to store rather than attach to the message
zzz
it's actually more efficient, because you know how many fragments there are, so you can allocate
zzz
also we combine multiple small fragments together
zzz
anyway, it's more efficient for me, sorry if it isn't for you :)
orignal
you always send last fragmnet first?
orignal
no problem just asking
zzz
checking...
zzz
I would say most of the time, but not guaranteed
orignal
I send in direct order
zzz
it makes it easier for me to pack small fragments together in one packet
orignal
because if the come sequentially I attach to current message
zzz
yeah, I get it
zzz
we also had a ack bug before 0.9.48 in SSU that reverse-order helped fix, doesn't matter for SSU2 of course
zzz
so it might be worth looking at it again
RN
Aloha y'all.
RN
Regarding process improvement: I've noticed recently that the topic in #i2p and #i2p-chat are not being updated when new versions are out. I don't mind taking care of this when I notice, but didn't there used to be someone tasked with this in the official process?