#i2p-dev (irc2p) | dev build 2.5.0-3 | Network reliability is degraded, please be patient as we work on mitigations

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 geti2p.net/en/misc/ratestats

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 LOL i2pgit.org/i2p-hackers/i2p.android.base/-/blob/master/routerjars/build.gradle

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