descriptor sync finished event after disabling UseMicrodescritors
Hi, what is the best way to find out when descriptor fetching is completed after temporarily disabling microdescriptors on a running tor client daemon? The temporary disabling of microdescriptors is done using this line in a python script using stem: controller.set_conf('UseMicrodescriptors', '0') Is there a better way than to try and re-try after 10 seconds in a loop via controller.get_server_descriptors() ? 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. Can I tell tor to "fetch now" directly after controller.set_conf('UseMicrodescriptors', '0') via an additional control command? kind regards, nusenu -- https://nusenu.github.io
On 07 May (14:11:14), nusenu wrote:
Hi,
what is the best way to find out when descriptor fetching is completed
I wasn't entirely sure of this so I looked at the code and turns out that when you get new microdescriptors, we only emit a BOOTSTRAP event but if the bootstrap is already 100%, nothing is emitted. I had hopes in "NEWDESC" until I read this sentence from the spec: This event is generated when new router descriptors (not microdescs or extrainfos or anything else) are received. So I think the short answer is, tor doesn't inform you of this. But, you could do the experiment of listening to _all_ events on the control port and see if there could be something I missed or some combination of events that could indicate to you this... hacky I know but one possible avenue.
after temporarily disabling microdescriptors on a running tor client daemon? The temporary disabling of microdescriptors is done using this line in a python script using stem:
controller.set_conf('UseMicrodescriptors', '0')
Is there a better way than to try and re-try after 10 seconds in a loop via controller.get_server_descriptors() ?
I'm not sure there is with tor itself :S.
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?
Can I tell tor to "fetch now" directly after controller.set_conf('UseMicrodescriptors', '0') via an additional control command?
I don't think this is possible as far as my memory goes for control-spec.txt. Cheers! David -- cEzKnCIRITTGQ0bcIesPTXZ4YIe0B0feRIrRBkFZXvo=
Hi David, 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.
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. kind regards, nusenu -- https://nusenu.github.io
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
participants (3)
-
David Goulet -
nusenu -
Roger Dingledine