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