I've just tried the patch from ticket 20082 and it works great for me. I was actually wondering why it was taking so long for a ephemeral hidden service to get registered in my SIM4Things project (I register an ephemeral service first to get Tor to setup the introduction points, then re-register it a la OnionBalance with a new identity). It's definitely a great improvement for my project!
Razvan
On Wed, Sep 7, 2016 at 6:40 PM, Ivan Markin twim@riseup.net wrote:
Hi tor-dev@!
Moving the discussion on the future of rendinitialpostdelay from ticket #20082 [1] here.
Transcribing the issue:
At the moment descriptor is getting posted at MIN_REND_INITIAL_POST_DELAY (30) seconds after onion service initialization. For the use case of real-time one-time services (like OnionShare, etc) one has to wait for 30 seconds until this onion service can be reached. Besides, if a client tries to reach the service before its descriptor is ever published, tor client gets stuck preventing user from reaching this service after descriptor is published. Like this: Could not pick one of the responsible hidden service directories to fetch descriptors, because we already tried them all unsuccessfully.
It has jumped to 30s from 5s due to "load on authorities". 11d89141ac0ae0ff371e8da79abe218474e7365c:
- o Minor bugfixes (hidden services): + - Upload hidden service
descriptors slightly less often, to reduce + load on authorities.
"Load on authorities" is not the point anymore because we don't use V0 since 0.2.2.1-alpha. Thus I think it's safe to drop it back to at least 5s (3s?) for all services. Or even remove it at all?
The questions are:
- Can we drop this delay? Why?
- Can we set it back to 5s thus avoiding issues that can arise after
removing the delay?
- Should we do something now or postpone it to prop224?
[1] https://trac.torproject.org/projects/tor/ticket/20082
Ivan Markin _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev