MASTODONTE DEVTEAM HOW TO
MASTODONTE DEVTEAM SERIES

While this is unfortunate, it doesn't really carry value for the purposes of observing network behaviour.

Thus, the probes disconnect at the same time.

They were controlled by the same piece of machinery, and that piece is unavailable at the moment.

MASTODONTE DEVTEAM HOW TO

In a system such as RIPE Atlas, there's much more going on than just pushing out commands and receiving results. The inner workings of the system can also provide a signal sometimes quite a useful one, if one knows how to interpret it.įor example what does it tell us when of a bunch of probes, that are otherwise measuring away quite happily, disappear at the same time? In other words the information about whether these probes are connected or not changed similarly. Metadata (noun): data that provides information about other data can be filtered in real time), under the hood the two systems use the same idea: take results off the queue and serve them to whoever is listening at the moment while doing real-time filtering. Even though RIS Live has a lot more result filtering logic (ASNs, peers, more and less specifics, etc. It's worth noting that the RIPE Atlas streaming concept / solution was later applied to make RIS data available in real-time, giving birth to RIS Live. Handling peak usage is still a challenge, but we expect that the service is here to stay. Of course it took more work to stabilise the solution and make it more scalable but what you get today is basically the solution that was introduced back then. Naturally, we combined the streaming prototype and the one-off measurements, tweaked the system here and there, and saw results appearing mere seconds after specifying the measurement. It was a moment to celebrate. The end result is that the one-off measurements are quicker to execute and report on (but not applicable when probes are disconnected and are more expensive to run) while regular measurements are more suited for periodic checks (and are cheaper to do). The two mechanisms coexist in peace, meaning neither of them has priority over the other. The controllers notify the appropriate probes as soon as the measurement is scheduled (which may be in the future), while the probes maintain a separate queue of these instead of adding them to their own 'crontab'. What this really means is that these kinds of measurements end up in a slightly different channel.

In a different universe (well, room), we worked on the so-called one-off measurements - the kind where the user doesn't want to measure on a regular schedule, but instead only once on a 'fast path'. what can possibly go wrong?' In that moment, the prototype of what became result streaming was born. In early 2014, one of our engineers was playing around with some new technologies and thought: 'huh, maybe I can connect this Atlas result queue here with a Redis store over there and put a few lines of node.js frontend on this machine.

MASTODONTE DEVTEAM SERIES

RIPE Atlas is 10 years old! To help mark the occasion, alongside the virtual events we have planned over the next two weeks, we'll be posting a series of stories surrounding the development of RIPE Atlas.

Mastodonte devteam