makepanic / globe Goto Github PK

see http://emberjs.com/blog/2014/01/14/ember-security-releases.html

The server-side Globe currently doesn't have graphs for different time periods. Moving this discussion here from [email protected].

Option 1: display graphs below each other (like Atlas does). Not pretty, but maybe the best solution we have without client-side JavaScript.

Option 2: merge all periods into one graph. I'm actually not sure how this would look like. Would all data points be on the same x axis? Then that's going to defeat the purpose of giving higher data resolution for more recent time periods. Maybe you can explain in more detail?

should we display running: false relays (relays that aren't running) in the top 10?

IMHO, the y-axis of the bandwidth graphs should always start at 0 so multiple relays can be compared by layout graphs side by side.

If I search for sysdev {at} leap {dot} se (which is an invalid search term to Onionoo), Globe attempts to search but never finishes.

Should fix the build process and manually downgrading the grunt-ember-templates package.

See: http://emberjs.com/blog/2013/08/14/ember-1-0-rc7.html

I need to replace the current implementation with something that only renders a part of the whole table. Right now it renders everything which can cause a huge performance bottleneck.

Can be combined with #1

possible libs:

• emberjs related
  • Ember-Listview https://github.com/emberjs/list-view
  • Ember-Grid https://github.com/Myslik/ember-grid
  • Ember-Table https://github.com/addepar/ember-table
• general
  • SlickGrid https://github.com/mleibman/SlickGrid
  • DataTables https://datatables.net/

Hi,

first of all thanks for Globe! It's a great tool! The issue I am reporting is purely cosmetical.

To reproduce it, find a relatively new relay for which there is no data before a certain time. Let's assume, a relay exists for 1 month, so there is no data older than that.

Select the "3 months" period tab.

You should see, that the graphs are showing the full time interval of three months including the first two months for which there is no data.

The selection bars below each graph, however, only show the time interval beginning with the first data; so in the case of our example it would only show the last month. Hence, the graphs and the selection bars are not aligned.

Cheers,
Lutwick

[14:51:35.411] GET https://onionoo.torproject.org/details?type=relay&order=-consensus_weight&limit=10 [HTTP/1.1 304 Not Modified 404ms]
[14:52:11.097] GET https://onionoo.torproject.org/details?limit=50&search=gab&fields=fingerprint,nickname,advertised_bandwidth,last_restarted,country,flags,or_addresses,dir_address,running,hashed_fingerprint [HTTP/1.1 200 OK 489ms]

In theory, the first query could be improved by adding the same fields parameter as the second query uses.

After doing a search, I'd like to go back to the home site (http://makepanic.github.io/emberjs-tor-onionoo/). Can you add a button/link for that?

The exit_policy_summary field either contains an "accept" or a "reject" element. If there is an "accept" ("reject") element, the relay accepts (rejects) all TCP ports or port ranges in the given list for most IP addresses and rejects (accepts) all other ports. But saying "none" for the element which is not contained in the dict is misleading. It would be best to only display either accepted or rejected ports.

I have 5 nodes, but globe show 7
https://globe.torproject.org/#/search/query=poiuty

See node.js version of Globe.

can't hurt to add more jsdoc
see http://usejsdoc.org/#JSDoc3_Tag_Dictionary

Error message:

Error: Assertion Failed: You have turned on testing mode, which disabled the run-loop's autorun. You will need to wrap any code with asynchronous side-effects in an Ember.run

Add pagination for search results via offset and limit.

see: https://onionoo.torproject.org/#methods

If a search, then select 'Bridges' view, visit a bridge page, and then use the back button of my browser it switches back to the 'Relays' view. Not ideal.

Example:

http://globe.rndm.de/#/relay/A1DBFFEF396F770974F361C9FBAE42103FEBFC6C

More nodes in the same AS:

https://onionoo.torproject.org/details?as=28573

something like GLOBE

The API replied with an error to your query. This probably means that you did not properly format your query.

https://onionoo.torproject.org/details?limit=50&search=poiuty&fields=fingerprint,nickname,advertised_bandwidth,last_restarted,country,flags,or_addresses,dir_address,running,hashed_fingerprint

HTTP Status 500

It seems the top 10 relays on the start page are listed in random order, or ordered by something I cannot figure out. Is this on purpose? Would it be possible to order everything as returned by Onionoo?

See related Atlas ticket for details: https://trac.torproject.org/projects/tor/ticket/9814

Globe makes the following request to populate its top 10 relays list:

https://onionoo.torproject.org/details?type=relay&order=-consensus_weight&limit=10&fields=fingerprint,nickname,advertised_bandwidth,last_restarted,country,flags,or_addresses,dir_address,running,hashed_fingerprint

It's probably confusing to list relays that are currently not running.

Can you add &running=true to that request?

The legend in the node.js weights graphs is cut off. See "consensus weight fraction" and "guard probability".

It makes sense to make "anonymous" a placeholder in the search input box. It sort of seems counter intuitive right now. And then maybe make "anonymous" the default, if the search string is empty?

When going from the index page to the search route with the search button, Firefox calls setupController twice.

The uptime designated in the graph and the reported uptime are not consistent. I realize that they may be based off of different sources/calculations, but if so, this should be noted on the page. If they use the same source, there's a bug, since the uptime in the graph for the last week has been 100%, but the uptime shown is little over a day.

To avoid requesting the details for a given fingerprint every time we could store the result on the first successful request.

Possible implementations:

localStorage:

• wide range of supported browsers http://caniuse.com/namevalue-storage
• limited space http://stackoverflow.com/a/2989317
• useless for more complex objects ( implemented and got QuotaExceededError at < 2000 detailObjects)

indexedDB:

• wip, see https://github.com/makepanic/emberjs-tor-onionoo/tree/indexedDB
• small amount of supported browsers http://caniuse.com/indexeddb
  -> polyfill available, but uses localStorage
• async -> have to wait result of a cache lookup to decide if i want to request from server or request from db

see: http://dygraphs.com/

advantages:

• canvas with ie fallback to vml
• better support for tooltips/data points ( no need for d3 circle hover tooltip )

Moving this idea here from the [email protected] thread.

In the long run it would be useful to cache Onionoo results on the server running Globe in node.js. Though I'd say don't prioritize this right now.

However, when you get to this, I suggest implementing a slightly different caching algorithm for the node.js version of Globe than for the client-side Globe. The server-side Globe could download the full details and bandwidth documents once per hour and cache it on the server. In particular, it could attempt to download it more often and include an If-Modified-Since header in its request, and it'll only get an update once per hour. I guess this requires some concurrency magic on the server side to avoid multiple downloads in parallel.

But as I said above: this is a fine future work task! For now, it's fine to make new requests to Onionoo.

Either the line colors or legend in the weights graph is wrong. The node "Tonga" is not an exit, but it has non-zero exit probability. Not sure about the other colors.