[tor-bugs] #10871 [Tor]: Download more microdescriptors with a shorter request

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Feb 10 18:59:18 UTC 2014


#10871: Download more microdescriptors with a shorter request
-------------------------------------------------+-------------------------
 Reporter:  nickm                                |          Owner:
     Type:  defect                               |         Status:  new
 Priority:  normal                               |      Milestone:  Tor:
Component:  Tor                                  |  0.2.5.x-final
 Keywords:  tor-client directory microdesc       |        Version:
  needs-proposal                                 |  Actual Points:
Parent ID:                                       |         Points:
-------------------------------------------------+-------------------------
 In a comment on #9969, karsten said:

 """
 A few thoughts:
 * Would it help if we implemented /tor/micro/all which is mentioned in
 dir-spec section 5.2 "Downloading router descriptors or microdescriptors"
 but which is not implemented yet? Of course, then clients would download
 the bulk of microdescriptors from a single directory.
 * Do we have to include full digests in requests, or would it be
 sufficient to ask for the first few digest bytes? Assuming that clients
 would only accept descriptors matching locally stored full digests. For
 example, requests could contain only the first 4 (or 8) base64 chars
 representing the first 3 (or 6) digest bytes. Directories could accept any
 multiple of 4 base64 chars.
 * Mixing the two ideas, how about we add a way to ask for 1/2, 1/4, etc.
 of all microdescriptors in a single request? The request could be
 /tor/micro/all/<base64-prefix>/<bits>, so that /tor/micro/all/A/1 means
 all digests starting with 0 binary, /tor/micro/all/w/2 means all digests
 starting with 11 binary, etc. Clients could decide how many requests to
 send from the number of descriptors they need, which may change over time.

 Each of these ideas requires us to upgrade authorities and caches before
 clients will be able to use them.
 """

 I'm giving this a separate ticket since it's going to need analysis which
 #9969 won't.

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


More information about the tor-bugs mailing list