This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/
[atlas] Global Traceroute
- Previous message (by thread): [atlas] Global Traceroute
- Next message (by thread): [atlas] Global Traceroute
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
scg at gibbard.org
scg at gibbard.org
Tue Jul 17 18:40:45 CEST 2018
> On Jul 16, 2018, at 1:49 PM, Vladislav V. Prodan <admin at support.od.ua> wrote: > > Hello. > > Thank you for your work. > Thanks for the feedback! > I will summarize my wishes: > > 1) After clicking the "Submit" button, the picture on the page should > be shown, that the request is coming or the text "Loading ....", so > that the user realizes that the request is not fast and did not hurry > to leave the page. Agreed. This is on my to do list. > > 2) If there is only one probes in the selected ASN, then after > selecting ASN, this probe should also be selected. This sounds like a good idea. I’ll work on it. > > 3) It would be desirable, that at https request > https://www.globaltraceroute.com/?probe=19178 the top fields of sample > #19178 are automatically filled. > > 4) It would be desirable, that at https request > https://www.globaltraceroute.com/?probe=19178&target=1.1.1.1 the top > fields of sample #19178 were automatically filled, in "Target Address" > the value 1.1.1.1 was set and the request for construction trails. > > 5) It would be desirable that when https request > https://www.globaltraceroute.com/?country=UK&target=1.1.1.1 randomly > take a probe from the selected location (UK), automatically fill the > top fields of this sample, the "Target Address" was exposed value > 1.1.1.1 and automatically sent a request to build the route. > > 6) I want to work correctly in the console programs curl, lynx and wget. > I’m curious about the use case for this. Using the Atlas API, if you already know the probe ID, you do the trace route with two http transactions. The first one creates the measurement and returns a JSON containing a measurement ID. The second, 30 seconds to a minute later (thus the slowness of the web app to return results) sends the measurement ID and retrieves a JSON containing the results. What I’m adding is: - making it easier to find the right probes - turning two requests into one - supplying Atlas credits to pay for the traceroute - reformatting the JSON output into a traditional text-based traceroute output, which is easier for humans to read but maybe less useful if you’re generating the traceroutes from a machine. Are you looking for a faster way to do manual requests and get human readable output, trying to point an automated system at it, or some hybrid of the two? And if automated, is the human-readable output ideal, or would you be better off dealing with something a more machine readable format? > 7) Notes at the end of the route that "Target Address" is anycast > address, especially for IP facebook, google, youtube and cloudflare. I’m curious about the use case again. Also, is there a good source for that data, or would this be adding one at a time as I discover them? > > 8) reCAPTCHA is certainly good against abuse, but is more accountable > limits on the number of requests. It is possible, after authorization > through Google or facebook, to raise the limits of requests. This is largely an issue of resources. Thanks to a generous donor, I have enough credits for more than a million traceroutes. If I run through that due to human users, that will mean this is far more successful than I expect it to be, and there should be no problem either getting more donated, or coming up with a revenue model to buy them through Atlas sponsorship. But if I open it up for machine-generated measurements, it wouldn’t be that difficult for a single user to run through a million measurements. So, I’m certainly happy to accommodate measurement by machine or in mass quantities, but need to figure out how to make it sustainable. I have a few models in mind for that, but again it largely depends on the use cases. > > 9) I want a correct recognition of ASN for gray IP - 10.137.128.1 > (10.137.128.1) [AS ???] > > 10) I want a correct ASN recognition for some other IP - 185.1.50.68 > (185.1.50.68) [AS ???] 12.581 ms > The IP address to ASN mapping is coming from MaxMind’s GeoLite2 ASN database. Putting in an override for RFC1918 would be pretty easy. Other corrections should go through MaxMind — it will fix a lot more than just this, and I don’t think it’s scalable for me to track every error in MaxMind. Thanks again for the feedback. It’s really useful. -Steve
- Previous message (by thread): [atlas] Global Traceroute
- Next message (by thread): [atlas] Global Traceroute
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]