Counting HS descriptor uploads
Hi, 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? Thanks, Michael
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=
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 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (3)
-
David Goulet -
Holmes Wilson -
Michael Rogers