Hi,
Better late than never I guess :S...
The Briar team is working on a new app that uses Tor hidden services, and
we're trying to work out when the server publishing a hidden service should
consider the service to be reachable by clients.
We've tried counting HS descriptor uploads via control port events, but we
found that when republishing a hidden service that has been published
before, the number of descriptor uploads seems to vary.
When republishing a hidden service, is it guaranteed that at least one copy
of the descriptor will be uploaded? Or are there circumstances where Tor
might decide that enough copies were previously uploaded, and still contain
up-to-date information about introduction points etc, so no new copies need
to be uploaded?
Descriptor upload can be quite chaotic and unpredictable. Reason is that there
are various cases that can make a service regenerate the descriptors and thus
republish them.
But, in all these cases, the descriptor will change as in for the "version"
but might not change the intro points information for instance. Such case
would be that the HSDir hashring changed and the service noticed so it would
immediately upload the existing descriptor(s).
Sometimes, 1 introduction points disappears and so a new one is picked up and
a re-upload is done.
And on and on, there are really various cases that can change it.
Not sure I'm fully answering the question but if not, let me know.
Cheers!
David
···
On 28 Jun (13:27:03), Michael Rogers wrote:
--
Fqe19T7kkqIztpNhCgmAQyHHCgY/ye8vvtNfYt0mb4s=
Knowing when an onion service is likely to be reachable would be useful for us too, as would less variation in the time required to connect to an onion address, or a clearer sense of progress when making a connection that we could relay to the user.
Holmes
···
On Tue, Aug 9, 2022, 9:01 AM David Goulet <dgoulet@torproject.org> wrote:
On 28 Jun (13:27:03), Michael Rogers wrote:
Hi,
Better late than never I guess :S…
The Briar team is working on a new app that uses Tor hidden services, and
we’re trying to work out when the server publishing a hidden service should
consider the service to be reachable by clients.
We’ve tried counting HS descriptor uploads via control port events, but we
found that when republishing a hidden service that has been published
before, the number of descriptor uploads seems to vary.
When republishing a hidden service, is it guaranteed that at least one copy
of the descriptor will be uploaded? Or are there circumstances where Tor
might decide that enough copies were previously uploaded, and still contain
up-to-date information about introduction points etc, so no new copies need
to be uploaded?
Descriptor upload can be quite chaotic and unpredictable. Reason is that there
are various cases that can make a service regenerate the descriptors and thus
republish them.
But, in all these cases, the descriptor will change as in for the “version”
but might not change the intro points information for instance. Such case
would be that the HSDir hashring changed and the service noticed so it would
immediately upload the existing descriptor(s).
Sometimes, 1 introduction points disappears and so a new one is picked up and
a re-upload is done.
And on and on, there are really various cases that can change it.
Not sure I’m fully answering the question but if not, let me know.
Cheers!
David
–
Fqe19T7kkqIztpNhCgmAQyHHCgY/ye8vvtNfYt0mb4s=
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi David,
Many thanks for the reply. I think there are still some basic pieces I need to get my head around in order to understand this:
1. When a brand new hidden service is created, what are the minimum and maximum number of HSDirs that Tor will try to upload the descriptor to?
2. Does each successful upload produce exactly one HS_DESC UPLOADED control port event?
3. If Tor can't immediately upload as many copies of the descriptor as it wants to, does it retry immediately or is there some delay before retrying? (We're trying to decide how to design the UX for this situation.) Are there any control port events we could use to track the status of the upload process in this case?
4. When a (non-ephemeral) hidden service is created and then the Tor process is stopped and restarted, what are the minimum and maximum number of HSDirs that Tor will try to upload the descriptor to after restarting? In particular, are there any situations where Tor might decide that it doesn't need to upload any copies at all after restarting, because the previously uploaded copies are still good?
Thanks,
Michael
···
On 09/08/2022 14:01, David Goulet wrote:
On 28 Jun (13:27:03), Michael Rogers wrote:
Hi,
Better late than never I guess :S...
The Briar team is working on a new app that uses Tor hidden services, and
we're trying to work out when the server publishing a hidden service should
consider the service to be reachable by clients.
We've tried counting HS descriptor uploads via control port events, but we
found that when republishing a hidden service that has been published
before, the number of descriptor uploads seems to vary.
When republishing a hidden service, is it guaranteed that at least one copy
of the descriptor will be uploaded? Or are there circumstances where Tor
might decide that enough copies were previously uploaded, and still contain
up-to-date information about introduction points etc, so no new copies need
to be uploaded?
Descriptor upload can be quite chaotic and unpredictable. Reason is that there
are various cases that can make a service regenerate the descriptors and thus
republish them.
But, in all these cases, the descriptor will change as in for the "version"
but might not change the intro points information for instance. Such case
would be that the HSDir hashring changed and the service noticed so it would
immediately upload the existing descriptor(s).
Sometimes, 1 introduction points disappears and so a new one is picked up and
a re-upload is done.
And on and on, there are really various cases that can change it.
Not sure I'm fully answering the question but if not, let me know.
Cheers!
David
_______________________________________________
tor-dev mailing list
tor-dev@lists.torproject.org
tor-dev Info Page