orignal
what is post termination hndler?
dr|z3d
it's about 7 commits so far, orignal, starting with git.idk.i2p/i2p-hackers/i2p.i2p/-/commit/0fd6c672d35889112cf05647fc44e0b2975155b1
dr|z3d
As for a succinct description, you'll have to wait for zzz for that :)
zzz
handling packets received after a termination was sent or received, and possible termination retransmission
zzz
see "Session Termination" -> "Data Phase" in our spec
zzz
and QUIC RFC 9000 section 10.2.1
zzz
I had nothing before
zzz
so I didn't save any token received in the termination ack
orignal
will check
zzz
so this was necessary for me to stop sending tokens in the handshake, and only send them with termination
orignal
so for new tokens
zzz
yes, but also it's for sending another termination when we get a packet
zzz
otherwise, if your termination got lost, the other guy could keep sending you I2NP for several minutes before he gives up, which is pretty bad
zzz
so this was always on my todo list, but bumped it up after I saw how bad my token problems were
orignal
that's how I do now
orignal
if packets keep coming I send termintion
zzz
yeah, you were ahead of me on that
zzz
how long do you wait for more packets?
dr|z3d
your SSU1 disablement stuff, zzz, still WIP or complete and ready for testing?
zzz
dr|z3d, if you're not firewalled it should be good, I think I still have some peer test issues, which is why I haven't announced it yet on my forum
dr|z3d
ok, thanks.
zzz
I've been running it on one of my routers for a few days. Please report results
dr|z3d
seeing a major drop in traffic or not so much?
zzz
hard to say, this is my -Akx router with NTCP2 disabled too, and ipv6 force-firewalled, so not representative
dr|z3d
ah. you're running your router in wheelchair mode. ok
zzz
yeah, it's my ssu2 stress test router as far as config, but that config makes it not so popular
dr|z3d
ok, will let you know how it behaves when I get around to enabling the config.
dr|z3d
will test it on something pushing some packets, so I should be able to get some idea of the difference in overall throughput.
dr|z3d
obviously this will be less and less relevant as the network migrates to the latest release. looks around 55% so far here.
zzz
it's already preferred over ssu1, so the effect will be just to move conns with old routers from ssu1 to ntcp2.
zzz
and very old routers won't talk to you at all
zzz
so not sure what the throughput effects might be. probably not much
zzz
what I'd be looking for is random NPEs or similar fails
zzz
caused by 1 vs 2 confusion
dr|z3d
ok, will keep an eye out.
zzz
thanks
dr|z3d
do you have any idea where we're setting the console/webapp cookies? those could do with tightening up a bit.
zzz
how so?
dr|z3d
getting console errors.. we should be setting those as same-site=strict and HttpOnly.
zzz
I looked at that a while back
zzz
it's deep in jetty
dr|z3d
the other thing is the conflict between consoles. I wonder if we can't use the port to append something to JSESSIONID name to differentiate.
dr|z3d
yeah, thought it might be jetty. couldn't see it in the source.
zzz
the problem is jetty completely changed the API from 9 to 10, so it's almost impossible for us to do anything in a way that would work for both standard and debian
dr|z3d
well, you say that..
zzz
you mean http vs https?
dr|z3d
I was thinking in the absence of anything better using javascript to manipulate cookies.
dr|z3d
no, I mean 2 or more consoles with conflicting cookies.. local console, remote console 1 over ssh, remote 2 etc..
zzz
ok, I looked at that a while back also
zzz
because I hit it going back and forth between http and https on the same router
dr|z3d
assuming the hostname's the same, eg localhost, then issue.
dr|z3d
localhost and 127.0.0.1, no issue.
zzz
the problem is that the cookie spec is port-independent. so it's unfixable
zzz
use different hosts, like localhost, 127.0.0.1, [::1], etc. that fixes it
dr|z3d
indeed
dr|z3d
session storage might be something worth looking at for _some_ things. or local storage where persistence over router sessions is desirable.
dr|z3d
if we could modify the cookie in transit, that would also work, append nonce or whatever to the cookie name. but I'm not sure that's possible.
dr|z3d
what we should be able to do, regardless, is modify the cookie with javascript to add the same-site and httponly fields.
zzz
both sound grim
dr|z3d
ok, well, I guess it's not a major issue; if I get something working with javascript worth using, I'll let you know.
zzz
ok I think i have termination retransmission working, going to watch it for an hour, that will be part 8
dr|z3d
great stuff.
zzz
yeah it's more important than I thought it would be, packet loss is real ))
zzz
orignal, how long do you wait after termination for more packets?
orignal
I don't have fixed time
orignal
I consider that a session is over and clean it up next time
orignal
I run cleanup every 30 seconds
zzz
ok
orignal
but I can do it more consistently
orignal
tell me the number
zzz
here's what I have right now, may change it later:
zzz
wait for 2 minutes after sending or receiving termination
zzz
reduce it to 15 seconds after receiving termination reason 1
zzz
retransmit termination (reason != 1) at 7/21/49/105 seconds
orignal
why shoud I wait 15 sec in this case?
zzz
in case of out-of-order packets
zzz
maybe 15 is too long, don't know
zzz
maybe not necessary
orignal
anyway will change it to consistent time
orignal
rather than random
zzz
and finally, I wait 250 ms before sending termination again after receiving i2np, relay, etc. (delayed ack) to limit sending
orignal
hmm
zzz
quic says it's important not to send too much when in "closing phase"
zzz
also not sure whether to respond to different ip/port or not while in closing phase. quic says you can if you want...
orignal
good point