[tor-bugs] #18967 [Metrics/Onionoo]: Add UUID to families in Onionoo

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu May 5 10:27:39 UTC 2016


#18967: Add UUID to families in Onionoo
-----------------------------+---------------------
 Reporter:  seansaito        |          Owner:
     Type:  enhancement      |         Status:  new
 Priority:  Medium           |      Milestone:
Component:  Metrics/Onionoo  |        Version:
 Severity:  Normal           |     Resolution:
 Keywords:  persistence,     |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+---------------------

Comment (by karsten):

 How would the Onionoo server generate such a UUID?  The part that I'm
 worried about is that two distinct Onionoo servers should ideally produce
 the exact same data, and that would require only using data like relay
 fingerprints as input for generating UUIDs rather than data the Onionoo
 server generates (randomly, using its system time, etc.).  The idea behind
 different Onionoo servers producing the same data is that Onionoo clients
 would be able to round-robin between multiple Onionoo servers.  That would
 fail badly if different Onionoo servers produced different family UUIDs.
 There are currently unrelated problems with data from different Onionoo
 servers not being exactly the same (encoding problems and the like), but
 those are bugs we can fix, whereas a new server-specific UUID would make
 this load balancing impossible.  (Note that this problem is different from
 UUID not being unique which I'm not worried about here.  It's rather the
 opposite, with UUIDs by different servers being unique when they shouldn't
 be.)

 Assuming we can work around the problem above, how would you treat the
 following scenarios?  1) Families AB and CD merge to ABCD; which family
 UUID do they use?  2) Family ABCD splits up into AB and CD; do they both
 keep their previous UUID?  And there might be even more complicated cases
 than those.  How would you handle these cases?

 I'm not saying that we cannot solve these issues, but I don't see an easy
 solution right now.  Maybe you have some ideas?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/18967#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list