#ls2 (irc2p) | #ls2 Proposal 168 review here 8 PM UTC Tues. Dec. 3

zzz ok. maybe not related to attack, but please research. especially startup issue because there shouldnt be 1k/minute incoming after 3 minutes of downtime

zzz routers should have given up and tried somebody else

dr|z3d was seeing something similar in dec. new router, uptime measured in seconds, being hit with 20-40MB/s traffic.

dr|z3d not a new router, new router session, sorry.

orignal do you see 1k/minute from the same source?

orignal if you see incming connections from different source how they could give up?

zzz no

zzz I mean they should have given up in the 3 minutes I was down :)

orignal but if you see from differnt guys

zzz with my new throttle I'm dropping 2500 connections in the first 10 minutes of uptime

orignal and what about OBEP?

zzz I don't know, that's why I'm asking for help ))

orignal how should OBEP give up if they keep receivein delivery instructions?

zzz good questions

orignal encrypted RI is a problem for me

zzz after startup I'm dropping 1500 SSU2 connections an hour

orignal I need to rewrite the code to move router's decryption to separate thread

orignal you have a risk this way

orignal that floodfills will be hijacked by i2pd )

zzz i2pd is ~ 33% of network. Let's see what % of inbound connections to my ff are i2pd.

zzz then we will know

orignal also please check DHT lookup

orignal how much it consumes on FF

orignal and FYI I have commited initial version of tree-based Kademlia

zzz I;ll have i2pd vs java data in two hours

zzz almost impossible for me to measure cpu of things on java

zzz I've been thinking about trees

zzz I think red/black is the right kind

zzz what did you do?

orignal ofc it's very first and non-optimal

orignal binary tree with 0 and 1 branch based on next bit

zzz so no balancing

zzz I was going to write my own but it wouldn't be balanced.

zzz red/black is balanced and is probably the right choice.

zzz it's a little complicated so finding a library would be a lot better.

zzz plenty of implementations out there

zzz Red/black is what the kernel uses all over

orignal ni balancing

orignal just by bits in hash

orignal look at my implementation KadDHT.h/.cpp

zzz yeah I see it

zzz nice and simple

zzz but I think balancing is a requirement

orignal I believe even this implemnetation will be fatser than what I have now

orignal plus there is room for optimization

orignal getting rifd of recusrion and memory pool

zzz ofc

orignal we know that this looks consumes around 25% of netdb thread

orignal *lookup

orignal on a FF

zzz doesn't look like you have find-closest-n-hashes yet? that's the hard part

orignal why?

orignal you find first then move 1 level recursin up assuming that branch is not there and try another

zzz seems like it's not easy to "back out" from the closest to find the n next closest. But if you know how, great :)

orignal it's the same as you find first closest, remove it and then find closests again

orignal but ofc you can do it more efficient way

zzz yeah but then it's O(n log m). Would be good to do it in O(log m)

zzz but in the "back out" you will have to go down paths in the tree you didn't take the first time

orignal yes

zzz search for one you just go down down down

orignal I have to go up to closest split and take another branch

zzz search for n you go down down down, then up down up down down etc.

orignal I know

orignal I don't say it's optimal

orignal just better than current dumb implemntation

orignal that's O(n*m)

zzz sure

zzz we are O(m log m) because we just sort them all

zzz not great

orignal yes, that's what I mean

orignal and would be nice how much CPU it consumes on FF

weko What is m?

orignal number of floodfiils

orignal n is number of closests. usually 3

weko Then algorithm O(log n) or O(n), don't now concretely.

weko Oh

weko No

weko Yes, log m ofc

zzz we were also doing O(m) for tunnel peer selection and I finally fixed that last month

weko Good

zzz baby steps

weko I don't agree

weko [15:33:56] <orignal> n is number of closests. usually 3

weko Or 2, as I know, for selection for local request

weko Look like O(log m * n ^ 2). Old algo O(m * n^2)

weko In worst case, ofc.

dr|z3d htop will give you internal process threads by name, zzz, so if you can provoke the sub-thread you want to monitor to do something demanding for an extended period, you should be able to monitor how heavy it is.

orignal top -H

orignal we name threads in i2pd

dr|z3d same in java.

zzz y'all are making bad assumptions about where our ff selection code is. Yes I said impossible which ofc is not true. But it is not something I'm going to do. If anybody is interested in researching hot spots in java code, go ahead. I'm busy.

dr|z3d the throttler, zzz, p=24/128 .. that's a fraction indicating the likelihood the connection will be dropped?

dr|z3d so 24 chances in 128, essentially?

dr|z3d I wondering a) how to make that a bit easier to read in the logs, and b) maybe how to do something visual with the stat in the sidebar.

zzz da

dr|z3d first should be easy enough, just convert it to a %age. 2nd, dunno. thinking...

zzz its for me not you

dr|z3d obviously :)

zzz turn it into a double and print out 20 digits if you like

dr|z3d now that would just be silly. :P

zzz 128 uses half the entropy that 100 does, that's why

dr|z3d > /128 * 100, round to int probably fine.

dr|z3d ok

dr|z3d not grumbling, don't get me wrong. it appears to be doing a good job.

zzz just a micro-optimization but it does make the printout a little wonky

zzz slight sacrifice in code readability, slight improvement in efficiency, close call

zzz some other day may have done it the other way

dr|z3d it's your code, your call to make :)

zzz thats really what all coding is. you make those decisions almost every line, you just don't realize it

zzz e.g. do you do A) :

zzz if (foo.bar() != null && foo.bar().baz())

zzz or B) :

zzz Bar bar = foo.bar();

zzz if (bar != null && bar.baz())

zzz you make that decision a hundred times a day

zzz jrandom almost always did A) and there's still a ton of it in there

zzz I think I usually do B), at least when I'm not in a hurry

zzz you seem to be usually in the jrandom camp

dr|z3d I take my lead from whatever's in the code that makes most sense. That's my template :)

dr|z3d over time I see more and more constructions that I start to understand, and then I might hop onto them.

zzz idealy you should never do A) without first estimating the cost of bar() and determining it's small

zzz all that happens in my head in a split second as I'm typing

obscuratus Jumping into the conversation earlier, do we have an idea how many of our users have internet hardware that can truely handle >1000 conncetions. My computer may think I can handle 1000 connections, but I'm not sure about everything downstream of my computer.

orignal tcp or udp?

orignal it's main difference

obscuratus If you're behind a router, don't both need a NAT table?

zzz generally the nat/firewall is the constraint, not the computer

zzz there both table size and table expiration issues

orignal I would say opposite

orignal a VPS has good network but weak hardware

zzz esp. on UDP

zzz we do periodic SSU pings when firewalled to keep the table entry alive

zzz it's "weak" CPU because you're sharing it, but there's no NAT table or OS limits issue presumably

zzz VPSes are designed for web servers

orignal I would assume VPS as tagret group for floodfills

obscuratus I guess one of the disadvantages of being an anonymous network is that we have difficulty knowing how many floodfills are VPS.

orignal how come? you see it by IP range

dr|z3d depends on the vps plan and the provider, orignal. not all vps' are created equal. some providers massively over-provision, others give you exactly the cores you paid for.

orignal I know

orignal let's assume $10/year shitty vps

dr|z3d then you definitely get what you pay for. aka fuck all :)

orignal but it's fine for floodfiil

dr|z3d that said, it's sometimes surprising what you can throw at that class of vps, even if plenty of your cycles are being stolen by other vps processes.