zlatinb
zzz: dethclock: e7qy5kc7ivqtnrbdn5ymx5nmbdedlrjkdchqmmkhud4ockrime5a.b32.i2p/?8e8877b59fef1045#8H9nEUDVZ2CNvTV6uQ2t84mWsqDqxbX73dpioLShkGfE
zlatinb
should be an easy fix, just grab getPorts() from outside the lock
zzz
zlatinb, was that just random or were you doing clock skew testing?
zlatinb
not clock skew but I was testing shutdown before the router was completely initialized
zlatinb
I mean the Router object was created, but it wasn't isRunning() yet
zzz
no, it was running
zzz
looks like a one in a million to me
zlatinb
runRouter() was called but I don't think it had established expl. tunnels yet
zzz
unlikely to be related to any soft restart hang
zzz
yeah udp was connecting in the bottom thread
mesh
zzz: btw, can I ask: is it normal to go /peers and see (NTCP) Connections that have been "Up" for 60+ hours?
mesh
I was thinking tunnels should last ~10mins unless I need to fix my firewall
zzz
thats a long time but not crazy
mesh
zzz: what does it mean? why would the router maintain a connection for so long?
zzz
are you ff?
mesh
176 ms / 2027 ms0.62 / 0.4750 hours <-- stuff like that is all over my /peers
mesh
zzz: yes I enabled floodfill
zzz
so now you're in a DHT, you'll tend to stay connected to others close to you
mesh
is that the idea, floodfills open long-lived connections to other floodfills?
zzz
they're not forced to be long-lived, they idle timeout like any other connection
zzz
but a lot of DHT traffic will keep you connected to your closest peers
zzz
thats what a dht does
mesh
ok. interesting. It makes sense that you would want to avoid constant connecting and reconnecting and the three-way handshake over and over. from a security perspective it's just surprising to see that
mesh
yes I see. you're right none of these connections are more than 60secs idle
zlatinb
deadlock happened again
zlatinb
so it's more frequent than we thought
zlatinb
and again
zlatinb
not good
zzz
there's another case a few lines above if rescan() returns false
zzz
probably easiest to just throw that on the timer also
zlatinb
any reason it's a SimpleTimer.TimedEvent and not SimpleTimer2.TimedEvent ?
zzz
ST2 handles both, we never went back and refactored all the old ST 1's
zzz
fixed as you suggested and pushed
mesh
dr4wd3: it would be nice if the router's uptime was more detailed than 'X days'
mesh
perhaps convert the uptime into a human readable duration string accurate to the hr: "4d4h" or "1w2d4h" ... it would still be a shorter string than "X days" and most users would probably be able to decipher it easily enough
mesh
actually all duration strings within the router should be formatted using the same human readable short string logic
mesh
when I look at /profiles?f=2 there's no reason all these times need to specify out "min", "sec" ... could just say "9m" or "274s"
eyedeekay
It looks like they are using the scheme as the router uptime from the sidebar to me, you get ms until a whole second has passed, seconds until you're a full minute in, then minutes, then hours, then days
mesh
eyedeekay: yes. but days is a bit too broad. if you're doing bandwidth calculations you really need to know roughly how many hrs the router has been up. so you end up having to go to /info and calculate how many hours from there
mesh
then again maybe even the router could tell you how much bandwidth you're going to use over the next 30d
eyedeekay
If you're trying to do any more-than-basic analysis of the stats the router provides gathering them automatically from the i2pcontrol API might be easier
eyedeekay
i2p.router.uptime, i2p.router.net.bw.* endpoints would be of interest
mesh
eyedeekay: I'm just trying to keep an eye on roughly how much bandwidth it's using per a day and then calculating a rough projection for the month
eyedeekay
Not sure what is best, but what is simple: I would do is ask the router how much it's been sharing in the past 15 seconds at intervals, calculate a running average for the 15 second sample, then multiply the running average by 21,600
eyedeekay
Wait is that right? no I need to divide seconds in a day by 15, not 4, I mixed up some units
eyedeekay
So 5760
mesh
eyedeekay: at least for me, I would like to know how much bandwidth the router will use until midnight of the last day of the month. basically the total transferred amount / the total number of hours of router uptime * (remaining hours in the month)
eyedeekay
"will use" is a little different from "allowed to use" but since I know what you mean, then I'm sure there's a way to get the figure you want and to do it well
eyedeekay
stream.con.lifetimeBytesSent
mesh
eyedeekay: yeah it's not going to be exact at all. I tend to just keep an eye on it every couple of days to make sure monthly bw limits aren't going to be broken by the end of the month.
mesh
wow gitlab is so complicated
mesh
eyedeekay: thank you for activating my gitlab account. I can login
dr|z3d
eyedeekay: I briefly discussed with zzz a monthly bandwidth limiter that hooked into the stats. maybe now's a good time to think about that.
dr|z3d
you'd set a data cap, and i2p would attempt to enforce it by adjusting your bandwidth accordingly.
mesh
eyedeekay: I'll stick the issues here for now: git.idk.i2p/mesh/i2p.i2p/-/issues
mesh
dr|z3d: that would be cool. I think for users that do have monthly data caps, the router could tell them immediately if their bandwidth limits will break the cap and perhaps even warn them if they're going to break the cap before the end of th month
mesh
these days most vps/servers offer a TB of monthly bandwidth so you kind of want the router to not use more than ~6-700gb
dr|z3d
yeah, that's the general idea, mesh. enforce an upper limit, let the router throttle where required, and notify the user when a throttle is active.
mesh
I love how sometimes the same restaurant delivers a dish that is amazing and other times delivers the same dish as absolutely terrible
mesh
clearly the lunch time cook is on drugs
mesh
zzz: btw git.idk.i2p/mesh/i2p.i2p/-/issues/5 is created. I think renaming these packages in i2p is probably the simplest solution
mesh
for now we can hack around it but it'll be an issue for anybody using modules and the streaming api
mesh
gitlab doesn't seem too slow for such a complicated app
zlatinb
idk if i2p will ever become properly modularized because android
mesh
zlatinb: I'm not asking for it to be modularized, just to not export packages from other projects
zlatinb
that's the side effect of no tusing gradle/maven and copy-pasting code instead :(
mesh
zlatinb: though it would be nice if i2p did implement automatic modules: branchandbound.net/blog/java/2017/12/automatic-module-name
zlatinb
well there's always manual patching :)
zlatinb
that's what i2p zero does
mesh
zlatinb: this would be as simple as adding a manifest entry "Automatic-Module-Name: net.i2p.core" etc
mesh
i2p-zero is cool but it seems to be abandoned
zlatinb
it was useful to nick ideas from
mesh
it doesn't run for me, don't know why
mesh
it's too bad
mesh
maybe I need to downgrade to < jdk17
zlatinb
you might want to look into some gradle plugin that does auto-modularization. The gradle build system is not used by default so no harm in making it fancier
zlatinb
i2p-zero is supposed to include its own jre.. ask "knaccc" in the monero channel on freenode
mesh
zlatinb: we don't really need actual modularization from i2p. if i2p just stopped exporting packages from other projects then the automatic module functionality provided by the jdk could do the rest
mesh
really it's just a matter of renaming these org.apache.http packages
mesh
of course full modularization would be nice but it'd probably require a good bit of work and like you said, android
zlatinb
i2p-zero did full modularization of i2p.jar router.jar SAM.jar mstreaming.jar and streaming.jar and maybe i2ptunnel.jar
zlatinb
it just did it manually
zlatinb
I don't mind renaming the packages fwiw
mesh
zlatinb: yeah I imagine they had no choice if they wanted to use jlink to produce an executable they needed to modualrize everything
mesh
we don't produce executables tho so it should be fine
zlatinb
well you don't really need to use jlink to produce executables, the easy install bundles do not use it
zlatinb
it's better ofc
zlatinb
actually, we could just modularize the jars as they go to mavencentral
zlatinb
even if they get used by android the module-info.class will just get ignored
mesh
zlatinb: won't android choke on .class files produced by 9+ jdks?
zlatinb
yes it will but wouldn't it just ignore a .class file that never gets loaded?
mesh
I might ignore module-info.class but it'll choke on any .class file that does get loaded
zlatinb
so yeah, build the jars with 8 then just patch a module-info.class
zlatinb
compiled with 0+
mesh
these days you can actually install openjdk17 under termux on android
mesh
though the permission stuff is a nightmare I wonder
zlatinb
idk if the android build process even uses mavencentral
zlatinb
and even if it does, it could be changed to use mavenlocal
zlatinb
oh it uses mavenLocal() already
zlatinb
so no harm in modularizing the jars before they get sent to mavenCentral
zlatinb
crazy gradle-fu
mesh
weird
mesh
mullvad is just another vpn that claims not to do logging
eyedeekay
Talking about how it calls out to ant to do the actual i2p.i2p parts?
zlatinb
yeah that's totally not the gradle way
zlatinb
even if ant were to be used it should have been the built-in "ant" that comes with gradle
zlatinb
but much cleaner would be to publish the jars to mavenLocal from i2p.i2p's gradle then just use those
eyedeekay
We have instructions for that that do work
mesh
wow linux went crazy and then I typed 'reset' (I think) and everything went back to normnal hehe
eyedeekay
Yeah you can do that with: ./installer/resources/maven-dev-release.sh $version in the i2p.i2p checkout
eyedeekay
then adding the build number you used to gradle.properties
eyedeekay
i2p.android.base has a really odd and complicated build setup, it's probably the most frustrating part of the whole thing, it's prone to hiding stuff from you