IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2023/11/21
~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Xeha
+acetone
+bak83
+cumlord
+hk
+poriori
+profetikla
+uop23ip
+weko
An0nm0n
Arch
Danny
DeltaOreo
Irc2PGuest21357
Irc2PGuest21881
Irc2PGuest5995
Irc2PGuest89954
Leopold_
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over1
anon2
anu
boonst
mareki2pb
not_bob_afk
plap
shiver_
simprelay
solidx66
thetia
tr
u5657
zzz woot, got keepalive phase 2 working
dr|z3d well done, zzz, you got it up on git?
zzz maybe in a while, if you promise not to merge it
zzz it's 2500 lines of diff
dr|z3d that confident it works are you? :)
dr|z3d holy bajeebus.
zzz a little gunshy after you merged the last one, really don't want to be stuck having to support it, at least not with high priority
dr|z3d bah, you got some quick feedback and a bug report.
zzz I just put it up on stats.i2p after finishing up local testing, will let it soak for a few days and start on cleanup
zzz sure, reports are good, but having to fix it quickly is not
zzz ask me in a week
dr|z3d as you wish. so in operation, are you seeing much in the way of perf improvements?
zzz ofc the initial latency is no different
zzz but the images all fill in quicker afterwards which is a huge deal
dr|z3d initial latency is mostly LS retrieval.
zzz ofc for phase 2 you need the patch on both sides
dr|z3d sounds promising.
dr|z3d if the soak tests look good, possible candidate for this forthcoming release? I doubt it, but I'm asking anyways :)
zzz big changes deadline is behind us
zzz and this is bigger than most
dr|z3d well, would be good to see a branch on github just to get a flavor of what you're up to, but up to you.
zzz it's the same flavor as the last one, just more of it
zzz I'll do it after more cleanup and testing
dr|z3d ok, thanks.
dr|z3d speaking of perf improvements, you may or may not be interested in: git.skank.i2p/i2pplus/I2P.Plus/commit/b99324658fc56a7f41e5fa44e84ec0cfcd74ab94
zzz related, this essentially bypasses streaming conn limits, and I haven't thought about what to do
dr|z3d what are we limiting to right now? I've probably modded that in +, but what's the ballpark figure? iirc it's total streams, not per dest?
dr|z3d as for what to do, maybe a UI-exposed config to limit # streams per dest.
dr|z3d (rather than relying on the server to limit streams/connections per client)
zzz doesnt matter what the number is, but with keepalive you can get unlimited http requests on one stream/conn
dr|z3d so the throttler/tunnel filtering will need to be reworked?
zzz dunno
zzz streaming doesn't know anything about http
zzz it could be done with the i2ptunnel filter stuff
zzz maybe
zzz or just leave everything as-is
dr|z3d sounds like a potential DDOS vector.
zzz ick, found another messy design flaw