[tor-bugs] #21095 [Metrics/Onionoo]: Accept more values for the "order" parameter

[Tor Bug Tracker & Wiki]

#21095: Accept more values for the "order" parameter
-----------------------------+------------------------------
 Reporter:  lukechilds       |          Owner:  metrics-team
     Type:  enhancement      |         Status:  new
 Priority:  Medium           |      Milestone:
Component:  Metrics/Onionoo  |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:  metrics-help     |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+------------------------------
Changes (by karsten):

 * keywords:   => metrics-help


Comment:

 Let's see.

 If you're interested in details documents, what you can always do is send
 one query for all details documents and order them locally.  That's okay
 for services that cache responses locally (Compass does this), but
 prohibitively expensive for applications that make requests on behalf of
 their user (like Atlas).

 Are we talking about Atlas-like use cases here?  If so, can you describe
 those in more detail?

 If you'd want to download something else than details documents, things
 are a bit more complicated, even in Compass-like settings.  In that case
 you'll have to do the thing above and then send one query per node in your
 ordered list.  This should be fine for 10 or 20 hits, but anything beyond
 that seems like a bad idea.  Or you also download all documents that
 you're interested in and keep them together with all the details
 documents.

 Let's assume we have a use case where extending Onionoo makes sense.  In
 such a case, adding `"first_seen"` and `"last_seen"` to the `"order"`
 parameter would be relatively easy.

 (Implementation hints: See this part of the code for details:
 https://gitweb.torproject.org/onionoo.git/tree/src/main/java/org/torproject/onionoo/server/NodeIndexer.java#n202.
 Use `SummaryDocument#getFirstSeenMillis()` and
 `SummaryDocument#getLastSeenMillis()`, and consider turning
 `orderRelaysByConsensusWeight` into a map with the current list entries as
 map keys and (hashed) fingerprints as map values.  Also make sure that
 ordering by multiple parameters gets implements, which was not necessary
 so far.)

 The other two fields that you mention, `"last_restarted"` and
 `"bandwidth_rate"`, would be more difficult, though doable if the use case
 is really convincing.  (Implementation hint: the trouble is that the
 necessary data is not available in `SummaryDocument`, so any extension
 would have to take into account that currently running Onionoo instances
 don't have the required data yet.)

 This could be a ticket for a new volunteer.  Be sure to write tests, this
 can break in funny ways!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21095#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online