IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2025/04/03
@eyedeekay
&zzz
+R4SAS
+RN
+T3s|4
+dr|z3d
+hk
+orignal
+postman
+snex
+wodencafe
Arch2
BravoOreo
Dann
FreefallHeavens_
Irc2PGuest11045
Irc2PGuest3921
Irc2PGuest59134
Irc2PGuest60113
Irc2PGuest60478
Irc2PGuest7448
Leopold
Onn4l7h
Onn4|7h
SigSegv
Sleepy_
Soni
T3s|4_
Teeed
acetone_
aeiou_
aisle
ardu
b3t4f4c3__
bak83_
cumlord
dickless
dr4wd3
enoxa
eyedeekay_bnc
notRN
not_bob_afk
phil
plap
poriori
profetikla
qend-irc2p
radakayot_
rapidash
shiver_
solidx66_
u5657
uop23ip
w8rabbit
weko_
x74a6
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