meejah transcribed 2.0K bytes: > Ivan Markin <twim@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev