IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#saltr
/2024/05/04
orignal 2RRY shouldn't produce execessive lookups
dr|z3d excellent, orignal
dr|z3d max 30/30s or 60/90s and it's good in my book right now.
orignal do you seomething now
orignal on your router with 2RRY
orignal like you did before
dr|z3d you mean see if it's banned?
dr|z3d not seeing it banned on 2 routers, so it's not triggering anything here right now.
orignal not banned
orignal you mentioned before you saw something in the log
dr|z3d make that 3 routers.
dr|z3d specifically relating to 2RRY, it managed to get banned before.
orignal the you saw excessive loookups
orignal in th elogs
dr|z3d yup, that was the ban reason. not seeing it for 2RRY.
dr|z3d since I relaxed the limits, I'm not seeing many routers hit them.
dr|z3d the next thing to look at is transit requests in a given period.
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 *than
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 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? ;)
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 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