[tor-dev] descriptor sync finished event after disabling UseMicrodescriptors (stem)

[Roger Dingledine]

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.
> 
> 1) torrc: UseMicrodescriptors 0 -> start tor -> fast to complete descriptor fetching
> 
> 2) 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