[metrics-bugs] #21378 [Metrics/CollecTor]: Archive bwauth bandwidth files

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Nov 5 20:57:21 UTC 2018


#21378: Archive bwauth bandwidth files
------------------------------------+------------------------------
 Reporter:  tom                     |          Owner:  metrics-team
     Type:  enhancement             |         Status:  new
 Priority:  Medium                  |      Milestone:
Component:  Metrics/CollecTor       |        Version:
 Severity:  Normal                  |     Resolution:
 Keywords:  tor-bwauth tor-dirauth  |  Actual Points:
Parent ID:                          |         Points:
 Reviewer:                          |        Sponsor:
------------------------------------+------------------------------

Comment (by karsten):

 Replying just to the parts where I wouldn't reply "okay, cool!":

 Replying to [comment:15 teor]:
 > Replying to [comment:14 karsten]:
 > > In the future, we can switch to fetching only those files that are
 referenced from votes, unless for some reason we want to have non-
 referenced files, too.
 >
 > How are bandwidth files referenced from votes?
 >
 > I don't think we will implement "bandwidth-file-url" from
 https://trac.torproject.org/projects/tor/ticket/21378?replyto=14#comment:6
 >
 > Tor 0.3.5? and later add bandwidth file headers to each vote, and we may
 add a bandwidth file hash in future. Once all authorities upgrade, you can
 fetch the bandwidth file if the vote contains headers.

 I guess I was thinking of 0.3.5 then. I'm not aware of any other plans.

 > >   - The relaydescs module runs twice per hour, so it's going to
 download the file twice every hour. Again, if we only fetch referenced
 files, we wouldn't download the same file more than once.
 >
 > I am not sure if we plan on implementing "referenced files" in Tor. Can
 you explain what you mean?

 Same as above: bandwidth files referenced from votes.

 > >   - I assume there are no plans that authorities serve bandwidth files
 of other authorities? That's different for votes which are cached by other
 authorities. Should be fine, but something to consider for the future.
 >
 > Votes are posted, fetched, and cached by authorities so that each
 authority can create a consensus.
 > There's no equivalent for bandwidth files, so we probably won't
 implement bandwidth file caching.
 > But if you tell us you really need it, we could work something out.

 Sounds reasonable. I don't think we'll need it.

 > > > 2) Teach
 [https://gitweb.torproject.org/collector.git/tree/src/main/java/org/torproject/collector/relaydescs/RelayDescriptorParser.java
 RelayDescriptorParser] to recognise the file
 > >
 > >  - While we're waiting for #21377, can we have a sample file to start
 writing some parsing code?
 >
 > moria1's votes have a bandwidth-file-headers line, but it's based on
 torflow's bandwidth file, so it only has a timestamp:
 > http://128.31.0.34:9131/tor/status-vote/current/authority
 >
 > The bandwidth file spec contains sample data:
 > https://gitweb.torproject.org/torspec.git/tree/bandwidth-file-
 spec.txt#n450
 >
 > We're working on version 1.2.0 of the format for sbws 1.0 in #28085.
 When sbws 1.0 is ready, we will update the spec with sample data from the
 latest sbws.

 Thanks! I didn't look just yet, but this should be a good start to write
 some code.

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


More information about the metrics-bugs mailing list