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

NarratorZ Is there any plan to merge i2pd's browser and java i2p's browser?

NarratorZ We may have carried out some duplication of work...

zzz checkin deadline day, translators you have 4 hours to go

zzz I'm writing the news entries

zzz eche|on, eyedeekay, do you have an ETA for MAC bundles I can tell the users? weeks? months?

NarratorZ Another new entry?

zzz NarratorZ, I always write the news around this time

NarratorZ I've checked the Chinese console and it's currently at 100%.

zzz you're a new translator for us, right?

NarratorZ yes

zzz ok

zzz in a few hours, I'll push the news to the "I2P News" resource, and announce it in Transifex. It will be two or three sentences. Your deadline will be Monday.

zzz that's the translation for the news feed you see in your router console announcing new releases and other info

zzz that's the way we do it every release, you can look at past announcements to see how it goes

NarratorZ 😉,Glad to help, I will start translating first time

zzz great, glad to have you on the team

zzz dr|z3d, re: p200, I didn't realize that the package came with CLI support

zzz did you see that there are shell scripts in src/deb/data/usr/share/pack200 ?

dr|z3d zzz: I think I noticed, didn't pay much attention to it. there's also the means to create a deb file and other stuff.

dr|z3d yeah, .deb and .rpm are provisioned, looking at the build.

dr|z3d in fact, they get built when you run mvn package.

dr|z3d does this change your stance on including it in canon? :)

dr|z3d I could probably have saved myself a little bit of time if I'd noticed the build.xml file.

dr|z3d or maybe not, seems like it's doing something slightly different.

zzz it's just a way for you to support building a pack200 updater with java 14+, should you choose to

dr|z3d java -cp /usr/share/pack200/pack200-@VERSION@.jar io.pack200.Driver "$@" seems like it could probably be run directly from ant if you've already got the pack200.jar compiled.

dr|z3d but yeah, well spotted!

zzz sure you could do it that way, or include the scripts, or both, it's just clues to how to go about it since the support is there

zzz I tested basic CLI yesterday, works fine

dr|z3d I've got an elf'd pack200 in /usr/bin/ .. not sure if that would get removed if I uninstalled java < 14, but I guess it would work with later javas while it's present.

dr|z3d still, you didn't answer my question. are you reconsidering your stance on inclusion? :)

zzz certainly not

dr|z3d if you carry on playing with it, the arguments I'm using to get the smallest possible zip file are: --strip-debug --effort=9 --modification-time=latest --segment-limit=-1

zzz if strip-debug loses the line numbers in stack traces, that's going to make it a lot tougher to diagnose problems

zzz yolo

dr|z3d ah, good point. I'll dig deeper, thanks.

dr|z3d -G --strip-debug

dr|z3d Strips attributes used for debugging from the output. These include SourceFile, LineNumberTable, LocalVariableTable and LocalVariableTypeTable. Removing these attributes reduces the size of both downloads and installations but reduces the usefulness of debuggers.

zzz want my crash test jsp?

dr|z3d sure

zzz > cat null.jsp

zzz <%

zzz Integer foo = null;

zzz foo.intValue();

zzz %>

zzz put in apps/routerconsole/jsp

dr|z3d I guess LineNumberTable provides the line numbers in the stack trace, so I'll reinstate debugging stuff.

dr|z3d what's that likely to do?

zzz just tests the error page

zzz when you go /null in the browser. you'll see the stack trace

dr|z3d ah, gotcha. thanks.

dr|z3d I'm working on the assumption LineNumberTable removes the line numbers, so I'm removing the strip-debug arg.

zzz sounds right, you could use /null to prove it, or to test new CSS shenanigans for the error page

dr|z3d thanks, the latter case is handy, sometimes hard to provoke an error to see what's needed to style it, so in the past I've just waited for unforeseen crashes.

zzz perhaps the finest coding in my career :)

dr|z3d oh, yeah, it's up there. definitely chocolate star territory :)

dr|z3d I got a question for you, re UDPSender.

dr|z3d MAX_HEAD_LIFETIME specifically, any reason it's set at 3s. was there any testing to arrive at that value?

dr|z3d and as a followup, does that get overriden by codel targets?

dr|z3d I'm asking because intuitively 3s sounds like an awfully long time for a packet to hang around.

zzz according to git blame, that's from 2012, so it predates codel, and I don't recall reason or testing

zzz it would be large on purpose, just as a failsafe, but probably not necessary now that we have codel

dr|z3d ok, thanks. maybe due for a revisit, perhaps. I'm testing at 1/2 that value right now.

zzz I doubt it ever happens in practice, probably better to remove it and let codel do its thing rather than play with tweaks that are untestable

dr|z3d and yeah, I figured packets would probably get evicted from head long before that max is reached with codel.

dr|z3d ok, so maybe just set it to whatever the codel target is, then?

zzz no, just remove the test completely, it's duplicative of what codel is doing

dr|z3d while ( (_keepRunning) && packet == null ) { then I guess, strips the max_head variable..

dr|z3d oh, wait.

zzz just while(keeprunning)

dr|z3d yeah

dr|z3d gotcha

dr|z3d or more like while (_keepRunning) { :)

zzz actually your way is right

zzz wonky jrandom code

dr|z3d never did quite understand value vs _value, but I try and not break things :)

zzz _ prefix is our convention for globals declared at top of class

dr|z3d ah, ok

zzz in java terms, "fields" vs local variables

dr|z3d gotcha, thanks.

zzz Jetty uses the same style but these days it's not very common elsewhere

zzz in i2pd you'll see e.g. m_KeepRunning; in android you'll see a lot of mKeepRunning, seems to be quite common way of doing it

zzz tl;dr just a naming convention, not language syntax

dr|z3d got it, thanks

dr|z3d discovered that variable in pursuit of optimal codelTarget and codelInterval values. it looks like the defaults are impeding throughput, based on "in the field" testing.

dr|z3d I've been using 50/1000 for a while, seems to give better results. 100/1000 I'm about to start testing.

zzz be sure to watch the stats if you're tweaking codel params

dr|z3d yeah, I'm looking at the drops and delays on graphs.

zzz and review the codel papers so you understand what the params do

dr|z3d yup, I think I've got a handle on the values.. I suspect different rules apply to I2P vs normal network operation.

zzz depends where the queues are

zzz some are in places where high latency is expected. the udp sender queue is very much a "normal network operation" queue

zzz where you don't want to tolerate a lot of latency

eyedeekay I am still waiting on Ech to reply to my mail, when he does I know more but for now estimate should be a matter of no more than a month, probably less

dr|z3d I guess that's also somewhat contingent on the size of the queues as well. I'm bumping those up to to test if throughput improves, as well.

zzz eyedeekay, for both x86 and arm? or will arm take longer?

zzz dr|z3d, might be a different stat for tail drop on queue overflow, not sure

eyedeekay Both should take the same amount of time,

zzz ok eyedeekay

eyedeekay I don't foresee any issues with the difference, other than the hardware itself

zzz sure. your answer is based on research on arm mac order/ship and setup time and est. time to decide who gets it?

eyedeekay IMO it will be Echelon, just need to clear that with him

zzz ok lets await his response, let's see if he's as optimistic as you are, given that you're assuming he does a lot but he said he doesn't have a lot of time

eyedeekay Alternative where I do the build and the signing involves him transferring the cert to me

zzz sure

eyedeekay We can do it that way, will just depend on what he says

zzz that's why I proposed you do the build and he does the signing/notarization

zzz which requires two round trips, but might be the quickest solution

eyedeekay If we need to we can do that now, I made it so it's possible for a builder who can't sign to generate an appimage that can be transferred to a signer, used to be they had to happen on the same machine at the same time

dr|z3d apologies if it's a silly question, but is the performance advantage from a native ARM binary for Apple really worth all the extra effort?

dr|z3d I mean, there's a point where good enough trumps absolutely the best performance available.

zzz don't recall but you might find old posts from zab about it on our forum

dr|z3d yeah, I think I recall those suggesting jbigi perf was better natively, but the question is "does it really improve things that much to be noticeable to the end user?"

zzz whether it was or not, we made the decision for it to be an official product, so here we are.

zzz check old meeting logs

dr|z3d ok

NarratorZ Perhaps disguising UDP traffic as TCP is a more obvious improvement

NarratorZ ISP don't like UDP.

zzz this is why I'm so prickly about making explicit decisions about official products and graduating things out of beta

dr|z3d sure, I get that. beta gives you an opt out.

NarratorZ Sorry, I seem to have digressed

dr|z3d UDP disguised as TCP sounds like a job for shadowsocks, no?

NarratorZ shadowsocks is just UDP over TCP

NarratorZ vmess and Trojan also

NarratorZ If we want to fool the ISP,faketcp would be good

dr|z3d github.com/wangyu-/udp2raw

NarratorZ yeah

NarratorZ NTCP2 is a bit old, we now probably only SSU2 can catch up with times?🤣

zzz a bit old? lololol

dr|z3d haha

dr|z3d a bit old, zzz. :)

dr|z3d we want a new protocol with every release!

zzz we just spent a year replacing 17-year-old SSU with SSU2, the takeaway is to kill our 4 year old child also? this is some House of the Dragon shit

dr|z3d haha

NarratorZ How about introducing libp2p, they also provide the Noise protocol

NarratorZ ssu can use 17 years is not without reason, the firewall on the udp restriction means not much, unless the direct blocking of IP

NarratorZ This doesn't mean that um... We're invisible enough.

NarratorZ Just an idea, I will find time to refine it

eyedeekay libp2p is great at being pluggable, but the best version of it is the Go one, last I checked the Java version was nowhere near as feature-rich

NarratorZ At least TCP and Noise are already supported

zzz we are not tor, we don't have pluggable transports, and we don't make a new transport every 6 months

NarratorZ Ah yes, I don't support pluggable transfers either. This is just stalling.

zzz news pushed to tx

zzz tx CLI will stop working in two weeks. gaaaaah

zzz ok, time to wrap things up

zzz eyedeekay, you ready for a checkin deadline? android and win bundle in good shape?

zzz oh yeah, french/spanish/italian/portuguese go to three plural forms, that's the tx change we avoided last time by a day

zzz let's hope it works

zzz translations pulled and checked in

zzz eyedeekay, holler when you're ok with the checkin deadline

zzz fun fact: this will be the smallest release by lines-of-diff in 7 years

eyedeekay zzz I'm ready, sorry I was stuck doing house stuff earlier

eyedeekay I got the last few things I needed in yesterday though

zzz super, here we go