[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #21095 [Metrics/Onionoo]: Accept more values for the "order" parameter
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs