On Mon, 16 Feb 2015 16:11:55 +0000 Leif Ryge leif@synthesize.us wrote: [snippity]
However, it seems like in the case of applications which are not HS-specific this will necessitate keeping another process running just to keep the HS alive. I'd rather see two modes: one as you describe, and another in which the ephemeral HS stays running until a new control port connection requests that it be stopped. To avoid allowing enumeration of running services, the "stop" command could require that the requestor already knows some details of the HS - either a cookie generated at creation time, or perhaps just the private key that was provided when it was started.
dgoulet suggested "Detach=true" as an optional argument, which is what the add side interface would look like if I did this.
This of course wouldn't result in crashed applications' HSes being cleaned up automatically, but having a few stale HSes sitting around isn't the end of the world. One approach for cleaning them up could be that tor could remove them automatically after it sees connection refused a few times.
I'm not quite sure how I feel about this yet. The code for doing all of this isn't that difficult, but I'd want to hear from a few more people about what the right thing to do here would be.
Most importantly since the `ADD_EPH_HS` interface uses key/value pairs for the port/target now, this would be easy to add on at a later date even if it doesn't get included in the first iteration.
Something to discuss at the dev-meeting if consensus hasn't been reached by then.
Regards,