#saltr (irc2p) | I2P+ 2.5.2+ >> i2pplus.github.io | skank.i2p | git.skank.i2p | purokishi.i2p | vituperative.github.io/i2pchat | natter.i2p | notbob.i2p | ramble.i2p | shreddit.i2p | cake.i2p | /msg an op for voice

dr|z3d_ Job lag / Message delay: 326μs / 7ms

dr|z3d potentially lower message delay in the latest + dev build. let me know how you get on with it if you update.

dr|z3d orignal: seeing Unsolicited DBSearchReply messages from 2RRY.

dr|z3d if those are legitimately coming from you router, you need to take a look at that.

orignal unsolicited?

orignal please elaborate

orignal so guys back to my question about exploratory

orignal why do we send back so few router idents?

orignal dr|z3d if they are coming from OBEP what can I do?

zzz orignal, state your case for why more is better

orignal my first question is why 3 not 1 or 10

orignal why more is better? because you send same message anyway

orignal if you send more other node sync netdb faster meaning better rate etc

orignal and in my implemntation expolratory is most painful thing, unlike floodfill lookup

orignal I'm redoing it

zzz before my time

zzz do you search backwards?

orignal waht do you mean?

orignal backwards

orignal so my question if waht would Java routers do if I start sending back 10 or even 32?

zzz backwards = query less-than-closest router if closest router didn't have it

orignal are we talking about exploratory or regular lookups?

zzz regular

orignal that was my questuin

orignal do we reply with closesst routers or better than ours?

zzz and I answered, DSRM replies are not necessarily closer than you. the docs say that also

zzz so, do you search backwards?

orignal thanks. I will fix it

orignal because currently I reply only with close to me

orignal serach backwards where?

zzz normal DHT says don't go backwards, stop if the closest doesn't have it. What do you do?

orignal you mean when I request or as FF when reponse?

zzz say 2RRY is closest-to-the key. You send lookup to 2RRY. He replies with DSRM, none of the ffs in the DSRM are closer.

zzz Do you stop the search there, or send a lookup to a ff farther away than 2RRY?

orignal in my last commit I check what the attempt #

orignal if less then 3 I serach backwards

orignal if more I stop

orignal the resons is what if 2RRY is malfucntioning

orignal started recently or belong to an adversary

orignal I just can't rely on the closests FF

zzz so before you did not search backwards, but now you do?

orignal before I stopped when receive DSRM without new routers

orignal if was wrong assumtion

orignal I try up to 7 attempts

zzz so you did search backwards, but only if you got new routers?

orignal no

orignal if I didn't get reponse from FF for example

zzz ok

orignal I stooped only if I got DSRM without new routers

orignal assuming I 've reached the closests

zzz we have always searched backwards (since current iterative search was implemented in 2011)

orignal that's not right

orignal so, again

orignal when I receive an lookup

zzz for reliability, and because a malicious ff could easily "blackhole" a destination

orignal what do I reply with?

zzz we always reply with 3 ffs, not necessarily closer than us

orignal thanks. will do the same

zzz do we need 10? 100? 255? I don't know

orignal back to explotaory replies

zzz what problem are you trying to solve?

orignal no. 3 makes sense because you also flod to 3

orignal it's reasoaable

orignal while exploratiry is different

zzz our search limit is 5

orignal the problem I'm trying to solve

zzz we don't really have a problem with new floodfills getting propagated. Actually with the attack we have the opposite problem. We learn about fake ffs too quickly

orignal exploratory is supposed to serach amoung regular routera

zzz yes

orignal there are bunch of them and they are not in DHT

zzz correct

orignal so if I had to run such heavy operation

orignal it's worth to use th results more efficiently

orignal if I get an ordered list of closests routers

orignal why only 3

orignal that's my problem

orignal expolratory if not about FFs, it's about non-FFs

zzz right

orignal and propagation of ordinary routers would improve the whole netwrok

orignal if a router has more fresh non-FFs

zzz you can send more if you want I guess. Does the spec say 3 is the max, or is there no max?

orignal then it has more to choose from

orignal specs says nothing

orignal but I don't know what you do it reality

orignal maybe you consder such reply malformed

orignal my proposal is to fit it in a single tunnel message around 1K

orignal so like 32

zzz looking...

zzz for regular lookups, the most DSRM entries we will "follow" is 8. for exploratory, I don't see a limit, but there probably should be a limit

zzz 32 won't fit in 1K, especially if encrypted

orignal approximately

orignal need to calculate

orignal so the whole idea is 1K

orignal let's agree how much we can put

zzz 8? 16?

zzz put as much as you want, not a fatal error, but I'm not going to chase all of them

orignal 16 seems good enough

zzz ok

zzz if it's too expensive to sort all your non-ffs to find the closest, you could probably just pick random routers in your keyspace if that's easier

orignal yes, I'm going to shrink list of routers to 4K first

orignal randomly

orignal and find closests from there

zzz sounds reasonable

orignal btw is there a timeout for exaploratory reponse?

orignal if I do it in a separate thread

zzz looks like our timeout is 30 seconds? it's all background, low priority anyway

orignal thanks. will adjust explratory timeout accrodingly

zzz not a critical value in any case

orignal when I send an exploratory request I need to set timeout hught

orignal higher

zzz right

orignal I wait 5 seconds now

dr|z3d orignal, re unsolicited messages, not sure how you can suppress those, just noticed you in my bans. possible attack strategy?

not_bob Looks like things in i2pd land are getting better.

orignal dr|z3d yes possible attack. But only source of them at 2RRY is OBEP

dr|z3d maybe see if you can filter them?

orignal if it's an attack they will send them as garlic

orignal if they don't do it alreday

dr|z3d keep an eye on transit request, looks like they're ramping.

orignal zzz, just double checking

orignal if we receive DSDR for exploratory

orignal do we send request to FF we received it from?

zzz up to you, who you send request to, when you do, if you do... implementation-dependent

zzz we put them on a queue and do it much (much?) later

orignal it's about expolarory

orignal due to it's nature

orignal if a FF claimed routers it's logical to ask him

orignal when to do it it's another question

zzz sure

orignal so you send request to that FF where you received reply from

zzz not for expl., no. we don't "remember" that when we put it on the expl. queue

orignal so what you do?

orignal you send expolratory request

orignal then get response with few routers in it

orignal you request closest ?

orignal maybe that's what causes excessive number of requsts?

zzz no, we explore very slowly

zzz we get the hashes from the DSRM, look for new ones, put the new ones on a queue. A separate process pulls one off the queue every now and then, and does a regular lookup for it

orignal how slow?

zzz looking...

orignal I need to understand this delay

orignal to not flood the network

orignal because it seems I do

orignal because I send regular request to all idents in exploratory immediately

zzz even the ones you already have?

orignal no, only new

orignal and not banned

zzz good :)

orignal but I do it rigth a way

orignal if I get 3 probably it's fine

orignal but if 16 I might get banned by dr|z3d ))

zzz looks like normally we do one lookup every 55 seconds minimum, 15 minutes maximum, can't figure out which is the usual case

orignal lol. I do it every 30 seconds

orignal will change it to 55

orignal but what you do with replies?

zzz shouldnt be a problem, like we said the other day my throttle is 14 in 2 minutes

zzz replies to the RI lookup? same as normal iterative lookup

orignal but might be more requests not about exploratory

orignal replies to expolratory request

orignal anyway will change to 55 secs + variance

orignal 90 sec actually if too few routers

orignal rebuilt 2RRY

orignal few unsolicited DSRM per second