On Sat, May 15, 2021 at 10:04:28AM +0200, nusenu wrote:
thanks for your reply and confirming that there is no event for this, so the best option is to make a simple loop and test every few seconds if the download is completed I guess.
What are you actually trying to do?
I ask because Tor will function just fine even when you don't have every single descriptor, and that's good because there are plenty of situations where you miss a few (e.g. because your dir cache doesn't have them) and it takes a while to get them.
So this notion of "the download is completed" is more ambiguous than you might hope.
That said, if you want to know about progress of fetching descriptors once you've turned off UseMicrodescriptors, that's exactly what the NEWDESC event is for. On the other hand, if you are wanting to track progress of new microdescriptor fetches once you've turned UseMicrodescriptors back on, I think your best bet might be to track STREAM events, since each dir fetch is a stream internally -- but either way you're going to need to keep a bunch of state on your side, about which descriptors you don't have yet, which ones have a current fetch going, etc. Which comes back to "what are you actually trying to do." :)
I also noticed that fetching takes significantly longer when microdescriptors are disabled temporarily when compared to adding UseMicrodescriptors 0 to the torrc file persistently and restarting the tor client.
Maybe simply because server descriptors are much larger than microdesc?
In both cases we fetch the same kind of descriptors.
torrc: UseMicrodescriptors 0 -> start tor -> fast to complete descriptor fetching
no torrc change -> start tor -> controller.set_conf('UseMicrodescriptors', '0') -> slow
Maybe (2) is slower because tor does not start the download directly after set_conf('UseMicrodescriptors', '0') is received.
When you turn off UseMicrodescriptors, that means Tor needs to fetch a vanilla-flavored (non-microdescriptor-flavored) networkstatus consensus document, before it can know which descriptors it ought to ask for next.
Tor has various internal events that check to see if it has all the directory info it wants, and that launch fetches of anything that's missing. Probably the delay you're seeing is waiting until the next one of those events triggers. You could send Tor a hup signal (or on the control port, "signal hup") to encourage it to reevaluate all the dir info it's missing.
For my various network health scanners, I tend to set "fetchuselessdescriptors 1" so I maintain both flavors of consensuses and descriptors by default.
--Roger