@eyedeekay
+R4SAS
+RN
+acetone
+orignal
+weko
Irc2PGuest63393
Irc2PGuest7270
Leopold
Minogami
Onn4l7h
Onn4|7h
ProRu
eyedeekay_bnc
j6
limak
not_bob_afk
profetikla
zer0bitz
zzz
-Akx now (occasionally) publishing D/E
zzz
dr|z3d, postman reports irc is running on i2p+, multihomed, please investigate the ls issue
zzz
I've asked if he has 'optimize for multihoming' checked and will pass along the answer when I get it
dr|z3d
ok zzz, thanks
zzz
I'm still thinking about how it could happen but low down my list for now
dr|z3d
I had a thought re the assigned letters for the congestion.
dr|z3d
letters/flags
dr|z3d
ideally they should be consecutive and not overlap existing letters, I'm thinking f specifically.
zzz
maybe an emoji instead?
dr|z3d
CDE I'm thinking.
dr|z3d
very funny.
zzz
Caps: PfR🍆
dr|z3d
c, capable, d, degraded, e, exceeded, or something.
dr|z3d
lol. I KNOW you're joking.
dr|z3d
nothing to prevent a visual representation of the state in the console, notwithstanding.
zzz
C is used in SSU caps which is a different namespace but still best avoided
dr|z3d
I was just thinking C, we have B as well.
dr|z3d
A, accepting, D, degraded (partial), E, exceeded, encumbered, evade.
zzz
caps = caps.replace("G", "🔥");
zzz
we don't need an "OK" cap, that's the default
dr|z3d
I know it's not consecutive, but it doesn't overlap f.
dr|z3d
what it does do is roughly follow high school marking schema. so sort of intuitive.
dr|z3d
so we only need 2 then?
dr|z3d
had to zoom to see that emoji. *chuckle*
dr|z3d
B, blocking some, C, congested?
dr|z3d
sorry, no C.
dr|z3d
*slaps self*
dr|z3d
so we could still go with D and E for consecutive.
zzz
still need G for no-tunnels-ever
dr|z3d
so we need 3 then?
zzz
yes
dr|z3d
can we mix and match letters and numbers? if so, no tunnels forever, "0" ?
zzz
putting up the proposals now, with D/E/G, we still have plenty of time to change it
dr|z3d
ok, maybe I'm just bikeshedding and it's not that important.
zzz
you're definitely bikeshedding but we can still change our minds, bring it up at the next meeting
dr|z3d
G kinda makes sense I guess, it's a counterbalance to f which is implies (though doesn't necessarily mean) high bandwidth.
dr|z3d
anyways, I'll stop now.
zzz
proposals will be up at bottom of the hour
zzz
postman reports 'optimize' option is enabled on both mulithomes
dr|z3d
what does optimize do exactly?
zzz
forces bundling LS in garlic, so client-server association will be sticky
dr|z3d
ok, thanks
dr|z3d
and when you say sticky, sticky as long as the http client tunnel persists, or just until the lease expires, even if a newer one arrives?
dr|z3d
for example, say I hit a few floodfills for a leaseset concurrently, get one, and then a newer one comes in a few millseconds or so later?
zzz
this is in the garlic
dr|z3d
so the first one wins in essence until the lease expires?
zzz
huh?
dr|z3d
ok, maybe I misunderstood. if the leaseset's in the garlic, that that as long as I have a connection to the server, I always have the leaseset?
dr|z3d
*that means
zzz
right
dr|z3d
ok. so what happens for non-persistent connections? I have a leaseset to the server while I'm talking to the server, and then I drop the connection.. I'll potentially get another multihome after that leaseset has expired. presumably.
zzz
right
dr|z3d
ok
dr|z3d
so on that basis, assuming I'm a single instance b32, there's no actual downsize in configured it as multihomed?
dr|z3d
*downside
zzz
bandwidth
dr|z3d
bandwidth, ok.
dr|z3d
so I'm trying to wrap my head around how you can acquire two differing leasesets and have them both stored in the netdb. that's definitely a head scratcher. ordinarily the newer one should push the older one out, no?
zzz
2 different dests (subsessions), DSA and Ed
zzz
that's the orignal complaint
dr|z3d
all I can think of is that i2pd isn't handling them in the same way java i2p is, when there's DSA and Ed.
dr|z3d
java just ignores DSA, right?
zzz
no. I reproduced it from here
dr|z3d
so what _should_ happen when a dest publishes both DSA and Ed?
zzz
whatever flavor client connects to, that's the LS that should get bundled back
dr|z3d
ok, well if you're stumped, color me stumped++
dr|z3d
this might be a bit of a stretch, but let's say there are a cluster of hostile floodfills out there trying various attacks to frustate the acquisition of leasesets.. any way to test for that? and could could they in theory cause the issue under discussion?
zzz
the way to get unstumped is reproduce it
zzz
assuming you don't want to set up an IRC server, standard tunnels with netcat on both ends would do
zzz
then find the problem, or retest with canon
zzz
if the problem is on your side, you'd have to audit half your codebase to look for some rev you missed, or mis-merged, in the last 10 years, or some other borkage
zzz
or, at that point, give up and tell postman to switch to canon
zzz
bitcoin update posted to their issue
zzz
proposals are live
orignal
it publishes both I guess
orignal
but if I connect to EdDSA one I expect EdDSA LeaseSet update rather than DSA
orignal
dr|z3d DSA leaseset comes from connection not from floodfill
dr|z3d
orignal: ok, hmm, thanks.