IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2024/01/22
~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Xeha
+bak83_
+cumlord
+hk
+poriori
+profetikla
+uop23ip
Arch
DeltaOreo
FreeRider
Irc2PGuest10850
Irc2PGuest19353
Irc2PGuest23854
Irc2PGuest46029
Irc2PGuest48064
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over
acetone_
anon4
anu
boonst
enoxa
glowie
mareki2pb
mittwerk
plap
shiver_
simprelay
solidx66
u5657_1
weko_
itsjustme How have you been Liorar?
Liorar itsjustme: SUPER busy, lol
Liorar for a long while my comp didn't have the ram to run extra stuff
Liorar had to wait till I got a new one with a lot more ram, so now I can do i2p plus all the other things I do
itsjustme nice :)
itsjustme I run everything on rpis
snex def offload server things onto pis or similar
snex le potatoes are very cheap
itsjustme thats what I do
StormyCloud In case you dont want to have a shelf of pi's at the house rpiservers.com
snex how can you not want a shelf of pis
orignal RU is blocking wireguard for a long time
weko <zzz> derp. RU blocking Wireguard
weko They don't block connections with russian ip only
weko I use WG inside county and it works fine
zzz lol didn't even remember what a 64KB NTCP2 frame was. Had to look it up. Yeah you don't want to go over that limit ((
not_bob zzz: Even if I'm behind 19 firewalls?
orignal yes NTCP2 frame is 64K - 18 (16 mac and 2 length)
orignal and we often send full frame
zzz I checked, we limit frame to 5 KB to minimize latency. I think that also helps do a kind of round-robin to keep one conn from hogging all the bw, not sure though
dr|z3d who was saying NTCP2 was much slower than SSU2 recently in i2pd. maybe that could be part of the problem, huge packets?
orignal NTCP2 is always faster that SSU2 in i2pd
dr|z3d yeah, my bad, I got that bass ackward.
dr|z3d <orignal> in our tests NTCP2 is around 3 times faster that SSU2
orignal why do you care about packet size in TCP? let OS decide
dr|z3d that's a good question.
orignal the only reason of 64K is 2 bytes length
zzz it's not packet size so much, it's about fairness across connections and when we call flush() on the socket
zzz chacha/poly is cheap so we don't try to make a huge frame
zzz we don't have a real round-robin algorithm anywhere in the router so we just have these little hacks to add some fairness
zzz might be worth revisiting the 5 KB limit though
orignal fairness? how 64K to send on one connection affect others?
zzz by using the bandwidth. We have to decide how much to send on one connection before we round-robin to the next one
zzz and because you can't decrypt anything until you have the whole frame, large frames add latency
zzz so we keep the frames relatively small
orignal what if you have to send long I2NP?
dr|z3d scale the packet size according to the detected latency? that's maybe another consideration for measuring hop latency.
orignal garlic is up to 62K
zzz sure, if it's bigger than 5K we send it, you can't split blocks across frames
zzz include first block; while total size < 5KB, include more blocks; send it
orignal well maybe I change to 16K
orignal ad see
zzz worth thinking about. I'm not saying 5KB is right. Also it was 10 years ago (!!!)
orignal NTCP2 was not 10 years ago
dr|z3d scale accordingy to latency, and/or scale according to total available b/w
zzz yeah, proposal created 2014-02-13 but we did it in 2018
zzz you going to do an i2pd release for the 64KB frame bug fix because that sounds pretty bad?
weko [13:41:40] <orignal> well maybe I change to 16K
weko I also wanted to suggest change to 16KB))
Quaddle Guys, do we have a site that deals with pentesting here on i2p ?
not_bob Quaddle_: NOt that I'm aware of.
orignal no, it's not a big bug
orignal currents release works fine
orignal in some rare cases Poly1305 verification fails
orignal when frame is close to 64K
zzz ok good
orignal weko has found it during the stress test
weko yes fixed