orignal
zzz, a question. Can an U router be an introducer or we should consider it error?
orignal
*as
dr|z3d
I think the answer is a categorical "no" orignal.
RN
does it matter who marked it as U?
RN
is it the local router that decides it is U and do I remember correct that U is unreachable?
RN
(to clarify- does the local rotuer decide RI {foo} is unreachable, vs {foo} says "I'm busy, call back later")
orignal
dr|z3d what do I do if see iH and this router is U with own introducers?
orignal
RN my question is what do in such situation
orignal
the use case it
orignal
a router was "R" later it became "U" after some false peer test or something
orignal
while another router still publishes it as introduces bvecause the session is still alive
zzz
sounds right, shouldn't happen normally, but things could have changed before or after the RI was published
orignal
so what do you do?
orignal
if iH is one with introducers
orignal
do you send relay requests twice?
zzz
we don't check caps, we just look for ip/port
orignal
same here
orignal
and you see that address uses introducers
orignal
do you try to etsblish a session to inntroducer through introducer just to send RelayRequest or give up?
zzz
no, that sounds like recursive introducers
orignal
and I guess if you receive new RI of introducer's session you terminate it of drop relay tag
zzz
we only keep track of tags from the handshake, we don't do anything when we get a new RI
orignal
it doesn't sound right
orignal
you keep publishing unusable introducer
orignal
because it's U now
zzz
maybe, but doesn't sound like a big problem. Our netdb system does not tell the transport system anything when it gets a new RI
orignal
not when you get new RI
orignal
when you republish your RI when introducers expire
orignal
you need to check if the session is still with R
zzz
maybe. we don't do it now
orignal
yes, this is just a suggestion
orignal
I'm redoing my stuff now
zzz
and the RI could be pretty old anyway, we don't have an up-to-the-minute knowledge of all the routers we're connected to
orignal
you keep receiveing updates like every 20 minutes
zzz
i guess we could invent an ssu2 'cancel relay tag' message
orignal
what for? if you het a new RI that's not longer publush introducer cap in that address you drop relay tag on your side
zzz
but we don't send RI out to everybody when things change, so it could still be 20 minutes
orignal
why can't you do it?
orignal
go through all seesion with repay tags and send RI to everybody once your introducer status changed
zzz
we could, but it would be a big burst of bandwidth, sending out an RI to 500 peers at once
orignal
don't send in once send it say in 10 seconds
zzz
or yeah, less if only to ones with tags
orignal
I'm trying to improve connectivity with U routers
zzz
or we could say a relay tag of 0 means cancel
orignal
where?
zzz
in the relay tag block
orignal
good point
zzz
but I don't think routers flipflopping between R and U is a big problem.
zzz
the problem is botnet U routers that are buggy or malicious or fake
zzz
the attacks have not stopped, they're just changing / moving
orignal
I'm trying to implement code in general
orignal
to cover all cases
zzz
you're just refactoring things then?
zzz
or fixing bugs?
orignal
on my side yes
zzz
great
orignal
mostly refactoring
orignal
and clear all corner cases
zzz
debian trixie will delete our i2p temp dir after 10 days of uptime: lwn.net/Articles/975565
zzz
we're going to have to do something
dr|z3d
can't you just update the timestamp on the dir periodically?
zzz
that's one of 7 options systemd.io/TEMPORARY_DIRECTORIES
dr|z3d
seems like the easiest to implement, and any stale i2p temp dirs that are hanging around will get deleted.
zzz
but the dir is not sufficient, I think it will reach in and delete individual files or subdirs
zzz
hangarounds arent' a problem, we remove the temp dir even on crash
zzz
heads up orignal if you use /tmp ...
orignal
no we don't
orignal
I thought that /tmp is used for local domain sockets only
zzz
/var/tmp too, it is 30 days
zzz
systemd fun