@eyedeekay
&zzz
+R4SAS
+RN
+StormyCloud
+T3s|4
+acetone
+hk
+orignal
+postman
+snex
+weko
+wodencafe
Arch
BravoOreo
Dann
FreeB
FreefallHeavens_
Irc2PGuest11045
Irc2PGuest48814
Irc2PGuest59134
Irc2PGuest60478
Irc2PGuest7448
Irc2PGuest90968
Leopold
Onn4l7h
Onn4|7h
Sleepy_
Soni
T3s|4_
Teeed
aeiou
aisle
ardu
b3t4f4c3__
bak83_
dickless
dr4wd3
dr|z3d
enoxa
eyedeekay_bnc_
hagen_
not_bob_afk
phil
plap
poriori
profetikla
qend-irc2p
radakayot
rapidash
solidx66_
u5657
uop23ip
w8rabbit
x74a6h
radakayot
when shutting down the router gracefully, i'm sending tcp rst instead of fin to close connection after sending termination message for all established ntcp2 sessions. does that cause any unwanted side effects on other i2p routers?
zzz
doubt it, but a normal close() would be better
zzz
a normal close() will ensure pending data and the termination message are flush()ed over; a reset() may trash them
radakayot
sometimes lingering takes too much time on shutdown. maybe SO_LINGER with 1 second FIN_WAIT will be better?
zzz
well yeah, you're waiting for the flush()
radakayot
thank you again, zzz. sorry for not being very active in the last 3 weeks btw.
zzz
if there's a nonblocking close() you could try that
zzz
then wait a couple seconds, then just exit and let the OS reset() the rest of them on the way out
zzz
no need for sorry, you don't owe me anything ))
radakayot
i could implement it but i don't want OS the take over lingering connections to close all sockets before exit.
radakayot
oh, i owe to you and to the other contributors a lot more than you think ))
zzz
yeah, close what you can normally
zzz
eyedeekay, would you please un-approve MR 240, I have more fixes to follow, probably tomorrow
eyedeekay
Ack will do
zzz
sorry for the churn, I woefully under-tested it
eyedeekay
Then I probably under-reviewed it, I'll have a look at the changes and understand what I wasn't seeing
zzz
not on you
zzz
didn't do what I wanted it to do, and bumped into an unfortunate 3-year-old bug
zzz
in other news, I went thru the rust router code and I'm even more astonished
zzz
to implement things like ratchets without assistance or complaints is quite a feat
zzz
altonen, a couple questions
zzz
1) I guess it's a rust thing, but somewhere down in the dependencies the build is pulling in UI things like X11, wayland, gpu, font parsing...
zzz
is there a way to hack that down some and reduce the binary size and build time?
zzz
2) I see you built your proxy on top of SAM. You lose some efficiency that way by having another socket out-and-in, and limited error handling...
altonen
the ui is optional, you can build the router for headless mode with cargo build --release --no-default-features
zzz
Blinded message
zzz
you'd have to move streaming out of sam for that
altonen
you make a fair point, i wanted to keep the core minimal and instead build proxies etc. on top of sam
zzz
ok so there's some native UI, it's not a browser-based thing?
altonen
i may reconsider it in the future
altonen
no browser based ui right now
zzz
got it
zzz
might be worth a note in the readme
zzz
I can see why you did it thru SAM for now, and 'yosemite' is a clever name
altonen
lol ty
zzz
but for, say, a high performance http server-side proxy, a i2ptunnel-style design might be better
zzz
even on the client proxy side, you can serve a lot better error pages with tighter integration
altonen
i will re-evaluate my approach once other things have stabilized
zzz
sure
zzz
just took me a while to find the streaming code and when I saw it was under SAM I went hmmm...
altonen
fair enough
zzz
3) looks like you hardcoded the I2CP bandwidth limits you send? that's probably holding back your i2psnark testing
zzz
because it tries to honor those
altonen
thanks, i need to take a look because perf on i2psnark was quite a bit worse than qbittorrent
zzz
not sure if you can set the limits higher than the router limits on the snark config page or not
zzz
but a lot easier if you just send it real values or higher fake values ))
altonen
emissary doesnt really respect any i2cp options, i've been lazy
zzz
ha. thats one thing you haven't been is lazy
zzz
back to streaming, the other reason to pull it out of SAM, is it could be really useful as a standalone lib, combined with a i2cp-client-side lib that it doesn't appear you have atm
zzz
for other rust client applications to use
altonen
is there a good reason why a client should use i2cp over sam?
altonen
it's quite a bit more involved with signing lease sets etc., sam is a pleasure to work with imo
zzz
well, until recently sam was all there was, unless you were in java
zzz
but now client-side libs are appearing in other languages
zzz
you're more of a sam fan than I am, I'm more neutral about it
zzz
where I2CP really has an advantage is mixed TCP/UDP applications like bittorrent+DHT. I think libtorrent will really struggle to implement DHT over SAM v3.3 subsessions, if they attempt it I think it'll be pretty awkward
altonen
i will think about, if people in rust community are interested in an i2cp client library i can probably make one
altonen
any particular reason why it'd be awkward?
zzz
I think 3.3 is a little janky, which I can say because I wrote it. But maybe not
zzz
but a decent client-side lib w/ 3.3 support may cover up the jank
zzz
for SAM testing you may also wish to try bitcoin
altonen
my line of thinking was to implement everything with sam and if it doesn't work, then sam needs to be updated, either as a proposal that you folks accept or a non-standard extension in emissary
altonen
i need to implement full v3.3 first to see how it's like though
zzz
yeah I get it, that's reasonable, it's the one design choice that stood out, doesn't make it wrong
altonen
but i'm reconsidering now
altonen
thank you for taking a look
zzz
any time. don't make any rash decisions based on my quick skim of it, nothing says you have to do it like others did