[tor-bugs] #13192 [Tor]: Collect aggregate stats of total hidden service usage vs total exit usage in Tor network

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Dec 8 14:48:29 UTC 2014


#13192: Collect aggregate stats of total hidden service usage vs total exit usage
in Tor network
-----------------------------+---------------------------------
     Reporter:  arma         |      Owner:
         Type:  enhancement  |     Status:  needs_review
     Priority:  normal       |  Milestone:  Tor: 0.2.???
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  SponsorR, tor-relay
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+---------------------------------

Comment (by asn):

 Replying to [comment:10 karsten]:
 > Replying to [comment:9 asn]:
 > > Nice code!
 >
 > Yes, I think we wrote some good code there together.
 >
 > > Small review:
 > >
 > > * When you do `digestmap_free(hs_stats->onions_seen_this_period,
 NULL)` do the elements of the digestmap get freed? I think you need to
 pass the `tor_free_()` func as the second argument?
 >
 > I think freeing elements would actually be harmful, because we're just
 storing void pointers (`(void*)(uintptr_t)1`) in the map.  We cannot
 dereference those pointers and free whatever we find at that address.
 Should we ask a C programmer to get this confirmed?
 >

 I'm sorry, I meant the key not the value. They key in our case is
 memdupped but I think it shouldn't be.

 >
 > > * BTW, wrt to this unittest
 `tt_assert(round_long_to_next_multiple_of(LONG_MIN,2) == LONG_MIN)`. It is
 the case in all platforms that `LONG_MIN` is even, right?
 >
 > Interesting question.  I'm pretty sure.  But even if not, the worst
 thing that can happen is that our unit tests break.
 >
 > I made two more changes: I documented the new config option in the man
 page as discussed in #tor-dev, and I changed the default config value to 0
 for two reasons: we should avoid that somebody accidentally turns on these
 statistics when running our branch; and we must avoid that we accidentally
 merge the wrong default value into master.
 >
 > Branch task-13192 contains the new changes as additional commits, and
 branch task-13192-2 is heavily rebased following the plan described above.

 `task-13192-2` looks OK to me. I don't see any new commits to the other
 branch.

 FWIW, we should soon (in a week or so) give this code to people to run it
 in their relays. At that point, the commented code of
 `extrainfo_dump_to_string()` should be included and enabled so that stats
 actually get to us. What do we need to do to enable that piece of code?
 Revise the proposal and post it to [tor-dev]?

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


More information about the tor-bugs mailing list