IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
orignal zzz, a question. Can an U router be an introducer or we should consider it error?
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:
zzz we're going to have to do something
dr|z3d can't you just update the timestamp on the dir periodically?
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