[tor-bugs] #14784 [Tor]: Implement status/fresh-relay-descs controller command

Tor Bug Tracker & Wiki blackhole at torproject.org
Sat Feb 7 21:13:05 UTC 2015


#14784: Implement status/fresh-relay-descs controller command
-----------------------------+--------------------------------
     Reporter:  Sebastian    |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  normal       |  Milestone:  Tor: 0.2.7.x-final
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:
Actual Points:               |  Parent ID:
       Points:               |
-----------------------------+--------------------------------

Comment (by atagar):

 Fantastic! This is great, thanks Sebastian! Few thoughts are...

 -----

 Lets have separate methods for getting the server and extrainfo
 descriptor. Unless I'm missing something there's no reason for 'GETINFO
 status/fresh-relay-descs' to return both. Maybe...

 {{{
 GETINFO status/fresh-descriptor/desc
 GETINFO status/fresh-descriptor/extra-info
 }}}

 Just picking 'desc' here to be consistent with the earlier methods. Don't
 really care much about the name. :P

 -----

 Nitpick but we're pretty inconsistent with descriptor naming...

  * 'GETINFO desc/*' and Stem call the main self-published descriptors
 'server descriptors'.
  * The dir-spec calls them 'router descriptors'... usually. It opts for
 'server descriptor' in section 6.2.
  * CollecTor calls them 'relay descriptors'.

 It looks like you're opting for 'relay descriptors' here. That's fine,
 just pointing out that we're inconsistent. Maybe we should have another
 ticket to settle on a name? The specs and CollecTor can easily change, but
 Stem's classes would be a problem since we vend those.

 -----

 {{{
 + DOC("status/fresh-relay-descs",
 + "A fresh relay/ei descriptor pair for Tor's current state. Not
 stored."),
 }}}

 I'm guessing the "/ei" is a typo?

 -----

 {{{
 if (router_build_fresh_descriptor(&r, &e) < 0) {
 }}}

 I don't know Tor's conventions but maybe != 0 is safer? In practice I know
 this is fine (presently it only returns negative or zero statuses) but not
 sure if this is like exit status codes where any non-zero indicates
 failure.

 -----

 {{{
 + if (e) {
 + size += e->cache_info.signed_descriptor_len + 1;
 + }
 }}}

 Do you know the use cases where a server descriptor can be generated but
 an extrainfo can't? Didn't know that was possible.

 Cheers! -Damian

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


More information about the tor-bugs mailing list