IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#i2p-dev
/2022/04/12
@eyedeekay
&kytv
&zzz
+Anomaly
+R4SAS
+RN
+RN_
+T3s|4
+acetone
+dr|z3d
+hk
+orignal
+postman
+weko
+wodencafe
Arch
Danny
DeltaOreo
FreeRider
FreefallHeavens
Irc2PGuest12106
Irc2PGuest32754
Irc2PGuest43409
Irc2PGuest77854
Nausicaa
Onn4l7h
Onn4|7h
Over1
Sisyphus
Sleepy_
Soni
T3s|4_
Teeed
aargh1
anon2
b3t4f4c3
bak83
boonst
cumlord
dr4wd3
eyedeekay_bnc
hagen_
itsjustme
khb
not_bob_afk
plap
poriori
profetikla
r3med1tz-
rapidash
shiver_
solidx66
u5657_1
uop23ip
w8rabbit
x74a6
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