[tor-relays] Metrics for assessing EFF's Tor relay challenge?
Lukas Erlacher
tor at lerlacher.de
Fri Apr 4 19:24:47 UTC 2014
Hello everyone (reply all ftw),
On 04/04/2014 07:13 PM, Karsten Loesing wrote:
> Christian, Lukas, everyone,
>
> I learned today that we should have something working in a week or two.
> That's why I started hacking on this today and produced some code:
>
> https://github.com/kloesing/challenger
>
> Here are a few things I could use help with:
>
> - Anybody want to help turning this script into a web app, possibly
> using Flask? See the first next step in README.md.
I might be able to do that, but currently I don't have enough free time to make a commitment.
> - Lukas, you announced OnionPy on tor-dev@ the other day. Want to look
> into the "Add local cache for ..." bullet points under "Next steps"? Is
> this something OnionPy could support? Want to write the glue code?
onion-py already supports transparent caching using memcached. I use a (hopefully) unique serialisation of the query as the key (see serializer functions here: https://github.com/duk3luk3/onion-py/blob/master/onion_py/manager.py#L7) and have a bit of spaghetti code to check for available cached data and the 304 response status from onionoo (https://github.com/duk3luk3/onion-py/blob/master/onion_py/manager.py#L97).
I don't really understand what the code does. What is meant by "combining" documents? What exactly are we trying to measure? Once I know that and have thought of a sensible way to integrate it into onion-py I'm confident I can infact write that glue code :)
Cutting off the rest of the quote tree here (is that a polite thing to do on mailing lists? Sorry if not.), I just have two more comments towards Roger's thoughts:
1. Groups of relays taking the challenge together could just form relay families and we could count relay families in aggregate. (I'm already thinking about relay families a lot because gamambel wants me to overhaul the torservers exit-funding scripts to use relay families.)
2. If you want to do something with consensus weight, why not compare against all other new relays based on the first_seen property? ("new" can be adjusted until sufficiently pretty graphs emerge; and we'd need to periodically (every 4 or 12 or 24 hours?) fetch the consensus_weights from onionoo)
Cheers,
Luke
PS: If you'd like me to support different backends for the caching in onion-py, I'm open to integrating anything that has a python 3 library.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140404/91639ac1/attachment.sig>
More information about the tor-relays
mailing list