~dr|z3d
@RN
@T3s|4
@T3s|4_
@eyedeekay
@orignal
@zzz
+Hikari
+Minogami
+Xeha
+acetone
+profetikla
+snex
+uop23ip
+weko
An0nm0n
Arch
DeltaOreo
FreefallHeavens
Gid
Irc2PGuest14111
Irc2PGuest2974
Leopold
Liorar_
Nausicaa
Onn4l7h
StormyCloudInc
admin
anon
anontor
anu
cheddah
itsjustme_
j6
limak
not_bob_afk
poriori_
qend-irc2p_
u5657
zzz
woot, got keepalive phase 2 working
dr|z3d
well done, zzz, you got it up on git?
zzz
no
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
no
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