~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4
@T3s|4_
@eyedeekay
@not_bob
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Over
+Xeha
+bak83
+cumlord
+hk
+onon_
+poriori
+profetikla
+r00tobo
+uop23ip
+weko
An0nm0n
Arch
Danny
DeltaOreo
Irc2PGuest53061
Irc2PGuest57148
Irc2PGuest60340
Irc2PGuest99578
Meow
Nausicaa
Onn4l7h
Onn4|7h
acetone_
anon3
anu
boonst
carried6590
mareki2pb
plap
shiver_
simprelay
solidx66
thetia
u5657
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
yeah
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?
Quaddle
h
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