Hi all, I was wondering if anyone managed to come up with a method of getting a probe selection via the API that is based on city. The web interface allows this, by searching for "place", which is subsequently handled by the Google Maps API (I think), and which then comes back with a number of probes on the map, in that given place. However I need this in the API, which only allows to select probes based on "area, country, prefix, asn". What I'm currently trying to come up with is a way to map, more or less, onto the list of ICANN specified probing locations for their DNS tests. This list is published here: https://tld-monitor.icann.org/nodes.csv I've been trying to go by the ASNs that the listed locations have their IP space in, but that frequently gives me a negative result (no probes present). The same for the prefixes themselves, of course. And just going by the enclosing country code is fine for a small place like Luxembourg, but not for a big country like Canada. So if anyone has any ideas on how to achieve this in a dynamic way (so as not to have to manually build and maintain a list of probes), I'd be very interested in hearing about that. Thank you, Paul Vlaar
Hi,
I was wondering if anyone managed to come up with a method of getting a probe selection via the API that is based on city. The web interface allows this, by searching for "place", which is subsequently handled by the Google Maps API (I think), and which then comes back with a number of probes on the map, in that given place. However I need this in the API, which only allows to select probes based on "area, country, prefix, asn".
I suspect we'll never be able to fulfill *all* the various wishes about how probe selection should work when scheduling a measurements ("I want to use blue probes, but not the square ones, and only three per ASN, selected by largest distance from the most sparse population of cats" kind). So we have a decent set of features directly supported by the measurement API, and ...
So if anyone has any ideas on how to achieve this in a dynamic way (so as not to have to manually build and maintain a list of probes), I'd be very interested in hearing about that.
... the next best thing is to use the probe API to make a probe ID selection, and supply that ID list to the measurement API. The probe API is pretty flexible, can do country selection as well as geocenter+radius or geographic bounding box. So I guess it can be of use here. See https://atlas.ripe.net/docs/rest/#probe, also the example section. Hope this helps, Robert
Robert, On 7/8/15 4:35 PM, Robert Kisteleki wrote:
... the next best thing is to use the probe API to make a probe ID selection, and supply that ID list to the measurement API. The probe API is pretty flexible, can do country selection as well as geocenter+radius or geographic bounding box. So I guess it can be of use here.
See https://atlas.ripe.net/docs/rest/#probe, also the example section.
Thanks for pointing me to that. I've just tried one of the examples listed: https://atlas.ripe.net/api/v1/probe/?country_code=de&is_public=true&fields=location,address_v4 However, I don't see the human readable location string show up in the results. Perhaps I'm reading over it? ~paul
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/08/15 16:17, Paul Vlaar wrote:
Hi all,
I was wondering if anyone managed to come up with a method of getting a probe selection via the API that is based on city. The web interface allows this, by searching for "place", which is subsequently handled by the Google Maps API (I think), and which then comes back with a number of probes on the map, in that given place. However I need this in the API, which only allows to select probes based on "area, country, prefix, asn".
What I'm currently trying to come up with is a way to map, more or less, onto the list of ICANN specified probing locations for their DNS tests. This list is published here:
https://tld-monitor.icann.org/nodes.csv
I've been trying to go by the ASNs that the listed locations have their IP space in, but that frequently gives me a negative result (no probes present). The same for the prefixes themselves, of course. And just going by the enclosing country code is fine for a small place like Luxembourg, but not for a big country like Canada.
So if anyone has any ideas on how to achieve this in a dynamic way (so as not to have to manually build and maintain a list of probes), I'd be very interested in hearing about that.
I do have code to do the selection part of the process, that can automate the selection of probes, if it helps I can put it on Github? e1000$./select_probes.py -h usage: select_probes.py [-h] [-v] [-l LOCSTRING] [-p POINT] [-r RADIUS] [-n NUMBER] [-f FIELDS] [-a MAXPERAS] [-d] optional arguments: -h, --help show this help message and exit -v, --verbosity -l LOCSTRING, --locstring LOCSTRING location string, ie 'Amsterdam,NL' -p POINT, --point POINT location as <lat>,<lon>-string, ie '48.45,9.16' -r RADIUS, --radius RADIUS radius (km) within which to select probes -n NUMBER, --number NUMBER number of probes requested -f FIELDS, --fields FIELDS comma separated list of fields to return (output is tsv) -a MAXPERAS, --maxperas MAXPERAS maximum no. of probes per IPv4 source AS -d, --includedownprobes include probes that are down (default: don't include these) e1000$./select_probes.py -l "Maastricht,NL" -r 20 -f id,asn_v4 14648 9143 11917 9143 16979 61956 438 9143 20036 12392 18396 12392 13308 9143 13656 12392 16243 9143 cheers, Emile
Thank you,
Paul Vlaar
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVxMS2AAoJEKxthF6wloMOSCQQAMOcb+t+kq0MMrO1HsvtAfRa g6C+Z/O3VA/gOKNhlvsQvmYmHxfa4tFxu2kqP2r43SCe48JGQwKDeOHCF7pCaeL8 lxmw7gXZauX3G9bGPwPCTOJNhAdnDT2u/XhCZLf9KLuhfllHNLFgR0FRmDe6z/Gu yp/4JBfcPNJux/QGmy8ps0JFxCYovY6OeiNtPq04qWitE+cMDqHhK8PiBD53MUl9 cntoK9aNTfiozvtvhtFLpm7vcv1kpWcB/t7L2L03P+vfeceFTbXY0TR7/4lnXVH5 3Rdz6iZqBMCiuoE43+vI38nku8jtS3kiPsAsqYqkJiZQBjh9j7oYfQCu0+EbDVAW G7GeBqvAm2T+1Lko/2rZpqorfmuu72WYT2/s4TwsMYMlsID7tB7EEeSo/Txzhsd8 l6HqEO+S6c+cVW8CaOL7zheUdgezaLK69FFHFrCiIAVZ1CSI8SirhAyQei8HAAh+ yyS4cpx/yPEqIeG0hZL1Z+KhPSmQoxLSnx8TIcUyBCCufWNclYjLGo/rcxxYU7z7 r2vGjT7Arx62o5+53nzLt8wThwZVR0oyysZoC0GzRJxFu/lAGWCyWs3GC3TGjukF BuoibQzH1RFm6mxyz+ypqQTzx+7eTmklcPgLPkesQA26TqXTN33G/n1hQecb74mX FyzWMfw78vEHcGvSXs2Z =EFxL -----END PGP SIGNATURE-----
Hi Emile, On 7/8/15 4:46 PM, Emile Aben wrote:
I do have code to do the selection part of the process, that can automate the selection of probes, if it helps I can put it on Github?
this looks great, I would love to be able to use your tool. If you can place it on Github, that would be very helpful. Otherwise, perhaps you can provide me a download link, or send it to me directly? ~paul
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/08/15 17:22, Paul Vlaar wrote:
Hi Emile,
On 7/8/15 4:46 PM, Emile Aben wrote:
I do have code to do the selection part of the process, that can automate the selection of probes, if it helps I can put it on Github?
this looks great, I would love to be able to use your tool. If you can place it on Github, that would be very helpful. Otherwise, perhaps you can provide me a download link, or send it to me directly?
https://github.com/emileaben/ripeatlas-probe-geoselect Only tested on my local laptop, so YMMV cheers, Emile -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVxQqxAAoJEKxthF6wloMOhToP/jZoIBDFHEBvKGWH8/L/uMbM yxaRYC0iED9YzPODiNKp/JyLeI6/XuGQJhMBzkXo7pflZLQvWSApUfJADcUO6AeS t+y3MZqJ9zJOz+dMlAqx9VLsk3DBZiwzdHs9qk2SgWYpCDoCnDDwyZQ/bs57fd3F opaitLaiI/VE1X8TbYRL/BK32GKuSj069VgqJ/FT1tYv/l09t5KhmvkqIKe8d/y4 dXxPiD/DhLTKJdxJpfTnMPVjhgywCWhAJUnr8GA4bkuxdFqULvu/xxDPN66Itl9M H2UcIYl9BkPM9sMfGAKtE25Xz2gs4+0UXCCvpjNKHqqA5LbGbv++WTUoNFkcY8th gzxtxj1k1/54+osZkjlj53G8z0ngOy3+f6kj7JNW5iP6kezotp8ijHnCOaubdwvU ASb1G5KbetV99gzq/SYSck2jn8MsYYkuvJVOStADLp5+QRmY6FJZqUaw4tjL52Zf TkU5PTxkl1F36pFlB0C1o404WCKQbva0RL9B8Y/V555uwVlKVAmiwvoSxeXiSxYO 8rPm53Xdro6Zu0HpvdU7fNgU29rIo2DEqD3n/L5IFUMyckfBJQuBRYVUzU2RnbRk o/u5kL+6sDJUzONNgHY9JJQx2sgRJgfcRCL/vPWG64mczYNlOe82aPtclrC3Jbj5 UeIfyYAwnJEPA2MS+TR7 =YOFe -----END PGP SIGNATURE-----
On Fri, Aug 07, 2015 at 09:44:52PM +0200, Emile Aben <emile.aben@ripe.net> wrote a message of 40 lines which said:
Thanks, but to avoid long searches on Github, could the people who contribute fork instead <https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib> and send Pull Requests?
participants (4)
-
Emile Aben
-
Paul Vlaar
-
Robert Kisteleki
-
Stephane Bortzmeyer