[tor-dev] Reducing initial onion descriptor upload delay (down to 0s?)

[isis agora lovecruft]

meejah transcribed 2.0K bytes:
> Ivan Markin <twim at riseup.net> writes:
> 
> > IMO an onion service should publish its first descriptor instantly. If
> > something happens afterwards and one has to fix the descriptor - deal
> > with it with backoff/delay to prevent DoS on HSDirs.
> 
> +1
> 
> txtorcon only ever waits for the first descriptor to be published (since
> at this point I presume the service is at least theoretically reachable)
> before alerting the caller that the service is "ready".
> 
> From a controller perspective it would also be nice to have
> more-granular feedback (maybe an HS_DESC event that indicates "waiting X
> seconds to do anything at all with this one") so that e.g. a GUI can
> make a nice progress bar that doesn't just sit there (i.e. if tor tells
> me that it will be 5 seconds before we even try anything, I can provide
> feedback every 1 second if I like).

Similarly to teor's earlier response in this thread, the change to a 1s timer
would be an easy patch (read: also a welcome patch!) which would likely see
inclusion in 0.2.9 stable, accompanied by plausible arguments for inclusion.
Given [insert handwavey "I'm not the person who does statistics/metrics around
here"] that most ephemeral onion services are well-behaving, from
txtorcon-using to stem-based things, to apps like ricochet which create onion
services and then later reload them, the initial descriptor upload should be
no overhead at all compared to a not-so-well-behaving service/app which
e.g. uploads ten descriptors per second.

> Perhaps you could achieve "less load on HSdirs" but preserve "at least
> one descriptor is uploaded right away" by selecting N random delays,
> where one lucky HSDir gets a 0 second delay and the other 5 get
> something random between 1 and 30 (or whatever).

Couldn't have a worrisome effect: that a client chooses the wrong HSDir
several times (in the process of the onion service unluckily reporting delayed
descriptors at precisely the wrong time w.r.t. the client)?

> p.s. I don't view ADD_ONION as being useful *only* for temporary
> services -- it's also the good API for applications that want to manage
> their own private-key material. For these, they might like to know when
> *all* descriptors are uploaded, etc.

Again, improving the control port notification interface is much welcome, and
patches are straightforward to review for timely inclusion.

Best regards,
-- 
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35
Current Keys: https://fyb.patternsinthevoid.net/isis.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1240 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160929/d506a6e2/attachment.sig>