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=
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev