#saltr (irc2p) | I2P+ 2.7.0-9+ >> i2pplus.github.io | skank.i2p | git.skank.i2p | purokishi.i2p | vituperative.github.io/i2pchat | natter.i2p | notbob.i2p | ramble.i2p | shreddit.i2p | cake.i2p | /msg an op for voice

dr|z3d I think, though I'd have to check, that we reject requests after a limit, bandwith tier dependent, and if the requests carry on after they're repeatedly rejected, ban hammer.

dr|z3d basically as soon as you're being dropped by a router, you should avoid making any more requests for a couple of minutes or so, try another.

orignal how do I know that my transit request is dropped?

dr|z3d you should be seeing refused when you make a request, aka fail.

dr|z3d not sure if we send an explicit refused msg, zzz will know.

orignal yes but if I'm an originator

orignal but what if I'm a participant?

dr|z3d if you're a participant, out of your control I guess?

orignal however you would ban me

orignal if you see too many requests comeing from me

dr|z3d yup, that's a bit sketchy I know.

dr|z3d it doesn't happen often, and even less for high bandwidth routers, however.

dr|z3d not easy to get banned, and the ban persists for 30m right now, so not fatal.

dr|z3d I guess you can also throttle on your end so you're not accepting too many requests from any one router. that could also help.

dr|z3d makes sense to do that so an attacker can't make a shit ton of requests through your router to try and get you banend.

orignal yes that's another issue

dr|z3d time to embrace transit request throttles!

dr|z3d let me dig up the relevant java source so you have an overview of what we're doing..

dr|z3d I'm a bit more lax that canon: git.skank.i2p/i2pplus/I2P.Plus/src/branch/master/router/java/src/net/i2p/router/tunnel/pool/RequestThrottler.java

dr|z3d *than

dr|z3d canon: git.idk.i2p/i2p-hackers/i2p.i2p/-/blob/master/router/java/src/net/i2p/router/tunnel/pool/RequestThrottler.java

zzz dr|z3d, got yer xvg graphs working, looks nice

dr|z3d oh well done you, zzz.

dr|z3d what are you using? the 12 monkeys svg renderer component and the apache renderer?

zzz no, the jfreesvg (GPLv3), unmergeable in canon due to license but perhaps you don't care?

dr|z3d not a concern, no.

dr|z3d it's a separate component, maybe there's some way to weasel out license compliance?

dr|z3d otherwise, if it only requires a subset of 12monkeys / batik, the compiled jars shouldn't weigh in at more than 4-500K.

dr|z3d I'd be very keen to see a branch with the code in, any which way :)

zzz you're already way off in the weeds with your AGPLv3 license that seems to me to be very non-kosher, dunno why you'd worry about weaseling. But not for us

zzz jfreesvg is about 50KB

dr|z3d haha, no, I'm not worried about weaseling, I meant you specifically.

dr|z3d yeah, that's the reason I identified jfreesvg initially, a lot more compact than 12monkeys/batik.

dr|z3d you got an svg you can upload to cake?

dr|z3d and if no weasels, then 12monkeys/batik I think has a compatible license.

zzz yeah I didn't have the energy to go thru some big package

dr|z3d I did some preliminary work compiling batik/12 monkeys, it appears most of batik, and probably most of 12monkeys, can be jettisoned, but I hear you. batik's a bit of a monster.

dr|z3d batik-svggen appears to be the most likely component required, not sure anything else is needed. that by itself is 220K.

dr|z3d jfreesvg has an alternative license available for sponsors, maybe it's worth throwing some coin their direction if you think the results merit it?

dr|z3d (or maybe not, the alternative license appears to be pretty restrictive)

zzz not doing a branch but here's your diff, you'll have to stick in jfreesvg and the rrd patch yourself, stats.i2p/docs/svg.diff

dr|z3d thanks

dr|z3d the rrd patch I've already got in a local branch, so it shouldn't be much work.

dr|z3d ok, svg rendering mostly working. had to mess around with the dimensions and take them from a bitmap definition to get the graphs to display (mostly) right.

zzz they looked fine to me and with svg it doesn't really matter what the dimensions are, but I couldn't tell if they were exactly right either

dr|z3d I had them being cropped so I was only seeing a clipped section of the graphs.

zzz ok so maybe you just had to rip some stuff out then, didn't have that problem here

dr|z3d yeah, minor. fixed. I've removed some crud in the svg files that shouldn't be there.

dr|z3d <!DOCTYPE..> specifically has no place in svgs.

dr|z3d I was suprised how faithful they are to the pngs at 100% scaling.

zzz but it needs the <?xml ... right?

dr|z3d np

dr|z3d *no

dr|z3d just needs <svg...>

zzz I had a choice of getSVGDocument() or getSVGElement(), the former had the <?xml and the <!DOCTYPE, if you don't need those just switch to the other one

zzz I figured the <?xml was required, it's in our susidns pic, but only spent 2 secs deciding

dr|z3d I'm stripping out the crud at source so it's not added, but thanks, I'll have a look at the alternative method.

dr|z3d we don't need a clipPath, either, totally redundant.

dr|z3d while we're not using gradients (maybe later?) I'll just remove the entirely useless <defs> section.

dr|z3d there's support for viewBox which is preferrable to width and size tags, haven't figured out how to enable that yet.

zzz shoulda just written your own svg lib them? ;)

dr|z3d :)

zzz anyway in the end it wasn't too hard, just took some headscratching and a few runs at it to get the two packages talking to each other right

dr|z3d yeah, you done good. appreciate the effort. hopefully you'll find a use for some variation in canon.

zzz yeah it's like dead nuts the same as the png, just crisper

dr|z3d haven't stat'ed the rendering times, should be faster?

zzz but I've never given a rats ass what the inside of an svg file looked like, so you're on your own island being picky about it

dr|z3d sure, not a problem. I'll pass any mods over if you want them.

zzz certainly not ((

dr|z3d LOL

dr|z3d I bet with your charm you could wrangle a compatible license exception from the dev.

zzz dunno about render times, but where this will really shine is lower memory usage; you can probably increase or get rid of the counter thingy that limits simultaneous renders to 2 or 3

zzz well I read that, he's offering binary licenses. He can't really wave his wand and relicense the source in a legit way

dr|z3d oh, I've done that already, long ago. iirc it uses maxCores() to render images.

dr|z3d he could make an exception for I2P I guess, but up to you if you want to pursue it. seems a shame to not be able to use it, but there's always batik as a fallback.

zzz ppl usually pick a license for a reason and are displeased with requests for a different one, in my experience

dr|z3d GPL3 is usually anti-TIVO type considerations. ie we don't want you profitting from our source without making your changes available. but sure.

dr|z3d nice gzip compression on those graphs. < 2K compressed.

zzz please report to rrd4j that we got it working, but it would be better if he made the ImageWorker methods public, so we didn't have to put our extending class in his package

dr|z3d you should probably have a word via github, you did the work, you're better informed as to what's needed from him to make things easier for us. me? I'm just a bystander :)

zzz as you wish

dr|z3d *thumbs up*

zzz this page en.wikipedia.org/wiki/Svg has the <?xml and docutype in the example, and this spec w3.org/TR/SVG11/struct.html also shows them

zzz maybe it works without but seems like they're supposed to be there

dr|z3d window dressing, not needed.

dr|z3d run whatever svg you like through this to see what you can get away with: jakearchibald.github.io/svgomg