@eyedeekay
&kytv
&zzz
+R4SAS
+RN
+StormyCloud
+T3s|4
+acetone
+dr|z3d
+hagen
+hk
+lbt
+orignal
+postman
+snex
+weko
+wodencafe
Arch
Danny
DeltaOreo
FreeB
FreefallHeavens
Irc2PGuest12735
Irc2PGuest42949
Irc2PGuest59134
Irc2PGuest89292
Irc2PGuest97859
Leopold
Onn4l7h
Onn4|7h
Sisyphus_
Sleepy
Teeed
aeiou
ardu
b3t4f4c3__
bak83_
cumlord
dr4wd3_
enoxa
eyedeekay_bnc
h3llf4wk3r
mareki2p_
not_bob_afk
poriori_
profetik1
qend-irc2p
r3med1tz
radakayot_
rapidash
shiver_
solidx66
u5657
uop23ip
w8rabbit
x74a6h
zzz
eyedeekay, MR 240 updated and back to you
zzz
going to need reviews on all the MRs soon as this is a quick 9-week cycle
zzz
dr|z3d, feeling better?
dr|z3d
thanks for asking zzz, yeah, on the up.
zzz
super. I see you merged a couple MRs. Would appreciate feedback on the server thread one, esp. on anything hosting a high-traffic server
zzz
and a headsup to stormy to test carefully before sticking on all the outproxies
zzz
doubt you'll see issues on the /dev/random one but keep an eye out
zzz
there's no way you need 10 PRNG buffers, you're just wasting memory, I'm confident 3 is fine
dr|z3d
sa far as I can tell, you're running requests in a thread pool rather than spawning a new thread per request, right?
zzz
there's a couple things going on with the threads change
zzz
there's a server thread pool and a client thread pool
zzz
the server pool is limited and the client pool is unlimited
dr|z3d
the server thread is limited by the number of concurrent streams configured, no?
dr|z3d
*therads
zzz
if you aren't careful about using the client pool in a server context you can open yourself up to DoS attacks
dr|z3d
gah. orignal typing day.
zzz
there's a separate barely-documented config for the server pool, defaults to 65, so it would predominate even if you set the concurrent streams higher
zzz
so part of the MR fixes that, to use whichever is higher
zzz
the main part of the MR is about not having a pool thread spawn ANOTHER pool thread for the normal GET/HEAD case, that was unnecessary
dr|z3d
ok, so if I understand you right, we bump the threads dymnically to whatever the clients (requests) are using? and yeah, noticed your HEAD tweaks, seem sane.
zzz
because you don't need to handle both directions at once. You process the request, and then process the reply, in the same thread
dr|z3d
ok, seems efficient. request/response handled in a single thread.
dr|z3d
I don't think I've yet noticed anything out of the ordinary, anyways.
zzz
ok. would be good to test on something like ramble. ramble seems really fast now, presumably due to pipelining
dr|z3d
ramble's always been pretty fast, on account of the hops.
dr|z3d
there's probably a memcache in there somewhere, I forget the specifics.
dr|z3d
obviously you're aware that anything you post on ramble.i2p is also available to the unwashed masses via ramble.pw
zzz
it's a lot of imgs, regardless, pipeline has to be helping that
dr|z3d
sure, can't hurt :)
zzz
no, but not relevant to the i2p side performance
dr|z3d
tangentially relevant.
dr|z3d
(in respect of hop count)
zzz
yup
dr|z3d
not much point trying to anonymize a server that also has a clearnet presence.
orignal
what?
zzz
think I found my first emissary bug, somebody holler when the guy comes back
zzz
hey altonen, found a possible bug
altonen
what kind of bug?
zzz
it doesn't look like you sort mappings when serializing them, unless hashbrown iterator is sorted, is it?
altonen
i think i do because initially i didn't and ran into issues with i2p, let me check
zzz
ok I'm not a Go person so I can't tell for sure
zzz
but yeah if you don't, i2pd won't care but Java will be really unhappy
altonen
java wasn't happy
altonen
routeraddress options get sorted, others dont, i'll create a ticket, thanks for the report
zzz
oh I see it, you're doing it in router_address. you need to do it in router_info also
zzz
safer just to do it in mapping.rs itself; most uses of mapping are in signed structures where it's required
altonen
you're right, i'll fix it soon
zzz
I'll put a bigger warning in the spec; you're not the first to trip over it
altonen
great
zzz
also altonen you probably didn't mean to check in Cargo.lock yesterday
altonen
i did, it's always been checked across the rust projects i've worked on, did it cause problems for you?
zzz
maybe? I know very little
altonen
it was intentional
zzz
ok, never mind
dr|z3d
yeah, Cargo.lock appears to be a valid checkin.
zzz
just looked wrong
dr|z3d
it's probably not what you think, zzz. open it :)
zzz
guess I'm a typical bug finder guy, finds one bug and thinks he's smarter than he is
zzz
yeah dr|z3d
dr|z3d
if you want to document progress etc, altonen, eyedeekay created a thread on ramble.i2p/f/I2P/5694/emissary-a-new-rust-implementation-of-the-i2p-protocols
altonen
i'll register and take a look tomorrow, thanks for the link, and idk for posting