Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:34:07Zhttps://gitlab.torproject.org/legacy/trac/-/issues/10871Download more microdescriptors with a shorter request2020-06-13T14:34:07ZNick MathewsonDownload more microdescriptors with a shorter requestIn 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? ...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.Tor: unspecified