heistp
simple STDOUT-only no memory mode?
Over at the OpenWrt forum someone pressed irtt into duty as OWD source for cake-autorate (here), which is pretty sweet. The problem is that most home routers that cake-autorate targets are often pretty RAM starved, so we need to periodically restart current irtt and run it for short enough interval that the memory hogging does not cause OOM. But then we are not really needing any aggregate statistics all we want is the last finished probe result on standard out so we can consume that. Would that be hard to implement for someone with essentially zero go experience, like me?
Hi Sebastian, I'm not sure how hard it would be, but it might not be simple, as irtt was written with that limitation to keep things simpler. So anyone implementing this might be cursing the author for not designing it without that limitation in advance. :)
If you wanted to try, you'll see somewhere in client.go that it creates a Recorder, defined in recorder.go. That makes a slice of RoundTripData sized to the max number of round trips expected in the test. Unfortunately you can't just "not create that" and call it a day, because they're needed to call OnReceived so that replies are emitted to stdout. You could try by adding items to RoundTripData as they are sent, and removing them as they are received, but you'll leak any round trips those replies were never received, so you'd have to remove those after some timeout. And you'd probably have to disable the calculation and emissions of statistics at the end, because without the expected round trips there, it won't go well. There may be more things that will have to be handled that I don't see at a cursory glance.
Sorry I can't dig into this. I do think it would be useful for this type of tool to work this way. In fact, if I had it to do over again, and Antler as well, I would try to implement both as a series of smaller tools each with a narrow function, with a common stdin and stdout format that can be combined in pipelines to achieve the desired result. Plus, Rust might be a better language for it, although the results from Go are also pretty good. My experience with Antler taught me that "config is difficult" for these tools, and I still don't feel I got it right with that, but I'll stop digressing now.
Thanks for checking in and I hope all's well!
Ach, this is a pity because it seems irtt may be of utility as a type of 'pinger' in cake-autorate, which monitors latency and bandwidth to help dynamically adjust the shaper bandwidths for variable rate connections. A workaround involving simply running and re-running irtt has been implemented here:
https://github.com/lynxthecat/cake-autorate/pull/337
but clearly it'd be nicer to have the continuous mode of operation (and c.f. https://github.com/heistp/irtt/issues/38).
@notsure2 would, by any chance, this (making irtt work in a continuous mode) be of any interest for you (mindful that you originally ported an early version of cake-autorate to go)?
I guess I will have a look at whether I can wing anything, worst case I take this as inspiration for a fresh implementation... you would recommend rust?
I can't either recommend it or not, as I haven't worked with it yet being tire kicking. Rust seems complicated for my taste, but for the purposes of a utility like this, the reduced system call overhead would be nice.
If OWD is all that's needed, I don't think it would be too hard to write a standalone utility to do that. I think all you need is a seqno on the request, with the client timestamp stored locally, then the seqno + server timestamp in the reply. But, as Dave pointed out before irtt was written, the protocol should be designed to avoid amplification attacks, e.g. by using a three-way handshake. This is just an arm wave.
It seems to me like #38 is essentially the same request as this one...
Thanks for the pointers! Avoiding amplification is not that hard, simply require the request packet to contain all the same fields asa the response packet... sure that only solves the amplification part not the general attack part...