zzz
the two drag-n-drop MRs are merged for snark and susimail, please test and report results
dr|z3d
still waiting for the keep-alive stuff to land
zzz
so please help out by reviewing and testing, and report results on the MR. After all, you've already merged an earlier version long ago, might as well try this one
dr|z3d
It's not one of my favorite pastimes, manually merging code, but I'll do it when the MR isn't too big.
dr|z3d
In this case, I'm inclined to wait it out, not least because there's no server-side MR so I can really give it a proper test.
zzz
the thing is, a review would be much more in your wheelhouse than in eyedeekay's
zzz
the client side, on its own, does have substantial changes that do take effect even in the absence of the server side, because it's persisting the browser socket
zzz
and you can also test it against my two servers
zzz
if you want to see the whole thing working end-to-end
zzz
anyway, it's still going to be a tedious merge for you, whether it's reviewed or not doesn't change the effort req'd
dr|z3d
maybe I'm doing it wrong, but having it merged makes a world of difference.
dr|z3d
as it stands, I have to _manually_ merge the code, that's to say, copy and paste from the MR.
dr|z3d
when it's merged, I can pull and then cherry-pick and let meld do some of the heavy lifting.
dr|z3d
maybe I should be pulling each of your branches down when I want to merge an MR and cherry-picking from those, but I'd prefer not to have to pull down 3 or 4 branches just to get at a single commit, you know?
dr|z3d
*single commit per branch
zzz
ok. that's more git-fu than I know
zzz
there's always another way with git but I stick to the basics
zzz
saw this google project which is interesting github.com/martinvonz/jj
dr|z3d
I don't mind testing, don't get me wrong, but 500 or so lines of manual commit is plenty to go wrong :)
zzz
then how about just a code review from you? no merging required ))
dr|z3d
jujistsu. another layer of abstraction and pain :)
dr|z3d
*jujitsu
dr|z3d
what are we reviewing?
zzz
the MR diff
zzz
what caught my eye about jujutsu is they claim to fix a lot of the things I find wonky about git, especially stashes and staging
zzz
and conflict resolution
dr|z3d
yeah, it's got some interesting ideas.
dr|z3d
it removes you from git, though, my strategy is usually to stare down git until I get it to work, and learn in the process.
dr|z3d
but maybe it'll work for you, after all your workflow and code churn is a lot different to most.
zzz
yeah I can't tell if you can forget about git or have to know everything about git to use jujutsu
zzz
not brave enough to try it atm
dr|z3d
back to reviewing your MR, I'm reading the section about not having a pool of I2PSockets, and asking if that's the best possible strategy?
dr|z3d
can we not just keep one in reserve?
zzz
best on what metric?
dr|z3d
latency I'm thinking.
zzz
no such thing as reserve, because a socket has to go somewhere, so the pool would be for places you've been before
dr|z3d
ok, well that seems like a waste if you're keeping sockets around from previous requests "just in case" you want to go there again.
zzz
since i2p is mostly single-user, and web pages are mostly single-server (you're not pulling css and fonts and images from multiple destinations) ...
zzz
it's optimized for the simple case, so it's "best" on the metric of "simple"
dr|z3d
ok, what about the inverse case, pulling resources from a single server from multiple local dests?
dr|z3d
:)
dr|z3d
I guess you just get the sockets you need per tunnel and nothing special required.
zzz
pooling sockets across multiple local dests (client proxies) isn't possible and would defeat whatever you're trying to accomplish with having multiple proxies
dr|z3d
yeah, wasn't suggesting pooling across dests, just wondering out loud if there's any penalty for pulling from multiple dests.
zzz
we're just not keeping multiple i2p sockets open. only one. so you lose the efficiency if you have multiple browser tabs open and quickly going back and forth
zzz
more optimization and complexity is possible in the future but this version is KISS
dr|z3d
ok, understood.
zzz
so for the 3 hops you only keepalive hop n if hop n-1 is keepalive
dr|z3d
not sure I understand that.
dr|z3d
one thing I'm wondering about is the timeout. 2m per connection could get expensive on the server quite quickly.
zzz
browser skt -> i2p skt -> server skt
dr|z3d
oh, ok, I was thinking entirely different hops.
dr|z3d
timeout.. let's say you have 4 visitors, each visitor has multiple dests requesting resources from your server..
zzz
so we don't keepalive the i2p skt unless the browser skt is keepalive
zzz
so we never have a bunch of i2p skts "floating around" waiting for reuse. only one
dr|z3d
ok
dr|z3d
so browser requests keepalive, only one socket is required (normally).
dr|z3d
what I'm concerned about is browser asking for 10 keepalive sockets from 10 different dests.
dr|z3d
for example.
zzz
well the goal is to reduce server resources by reusing sockets. ofc that could be "expensive" to have them sitting around waiting
zzz
browser only talks to one client, one local dest
zzz
sure it could have sockets to 10 servers
dr|z3d
yeah, I'm probably overthinking it. your average server can probably handle thousands if not 10s of thousands of open sockets without too much issue.
zzz
but we'd close the other 9 on the client side
zzz
we limit to something like 30 by default
zzz
on the server side
zzz
a long way from thousands
dr|z3d
yeah, non-issue then.