On 5/5/12 16:43 , Jérôme Benoit wrote:
On Sat, 05 May 2012 12:22:15 +0200 Philip Homburg<philip.homburg@ripe.net> wrote:
I don't know about SamKnows, but for RIPE Atlas, talks contain a lot of details about how the system works. To the extent that there is a well defined road map, we talk about it. I'm having hard time to find the roadmap and the talks on the RIPE Atlas web site as a public user with no account. But I might have not searched enough. Where are they ?
There is not a single comprehensive road map. What is there, is just bits and pieces. Most of it was discussed during the most recent RIPE meeting. The talks by Robert and Daniel should be online. To list some things that have been mentioned: * TTM shutdown, Atlas is expected to provide functionality similar (but not identical) to what TTM provides * DNSMON gets moved to Atlas * Roll out of Atlas Anchor boxes (regular PCs at well connected locations that can serve as the target of measurements and as a more powerful Atlas probe) * Measurements for IPv6 launch * Better UDM interface * UDM for all RIPE members (instead of just probe hosts and sponsors)
As much as I like open source projects, I really don't see it working for the current Atlas system. It work very well, we do it since age but we took a very different approach :
The measurement agent is designed as a standalone component with that requirement :
* Must be portable, that mean all measurements must be implemented natively. * Datagram-based measurement are divided in four components - packets forge - packets injection - packets capture - packets filter Each component work is mapped to a dedicated thread (an Lwt job more precisely, which bring in a very nice way to manipulate packets in a asynchronous fashion). Note that for Atlas, it has to work on an underpowered CPU without MMU and with 8 MB of memory. * Other measurement can be mapped with a plugin dynamically loaded (the API is not stable yet) * A syntax (that is not yet finished) permit to express what a measurement will do. The syntax is thought as a way to express what the software functionalities are and how each component interact with each other. I give a working example just to show the idea :
However, I think this would be a great area the community can work on. Plenty of people has expressed interest in something more general than what is currently implemented in Atlas. So if people can come up with a design that is both secure and can work on 8 MB probes, then maybe that can be used to create a common interface to the different measurement platforms.
Probe are just too fragile, the whole system is too complex. ?
I fail to understand this argument. Every single piece of software is a complex system, that has never ever be an argument to not opensource it. And for the fragility, probably a design issue of the probe (but I can't known for sure, no source code to review).
Running an open source project is not a goal of the RIPE NCC. If that's supposed to be a goal then the members will have to ask for it through the appropriate channels.
Does releasing the Atlas source benefit the RIPE community? I don't know. Fortunately, that is not my decision to make. RIPE call. I think RIPE have made a mistake by not going opensource since the beginning. I guess opinions differ there.
If you have a dedicated team in an open source project, then you should be able to duplicate our work. You can always for feedback on any design, or ask how we do things. I do not know the list of active measurements an Atlas probe cover.
At the moment, ping, traceroute, tdig (dns), httpget, sslgetcert.