[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #27248 [Core Tor/Tor]: Can we make our node-related structures more efficient?



#27248: Can we make our node-related structures more efficient?
-------------------------------------------------+-------------------------
 Reporter:  nickm                                |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.3.5.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  035-roadmap-master, 035-triaged-     |  Actual Points:
  in-20180711                                    |
Parent ID:  #27243                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by teor):

 I am suggesting that Tor keeps each relay field in one place (usually the
 node_t), rather than up to 4 places (routerstatus_t, microdesc_t,
 routerinfo_t and node_t).

 For example:

 There is currently an IPv6 address and port field in routerstatus_t,
 microdesc_t, and routerinfo_t (and maybe in node_t).

 Most clients use microdescs. They currently store IPv6:
 * in the microdesc_t, when using consensus methods 27 and earlier it is
 the relay's IPv6 address, otherwise it is zero
 * in the routerstatus_t, when using consensus methods 27 and later it is
 the relay's IPv6 address, otherwise it is zero

 Directory authorities and directory mirrors also store the same IPv6
 address in the routerinfo_t.

 We can put an IPv6 address in the node, and make all of Tor's code use
 that IPv6 address. (Except maybe on authorities, if they need to know
 "IPv6 in the descriptor" and "IPv6 in the consensus" at the same time.
 But they mostly want to know what's in the descriptor.)

 For every field in microdesc_t, routerstatus_t, and routerinfo_t we can:
 * put it in the node, or
 * remove it, or
 * decide to parse it as needed.

 For routerinfo_t, we can also decide to:
 * not parse relay descriptors on directory mirrors, and
 * keep some authority-only routerinfo fields in a cut-down version of the
 structure.
 But routerinfo_t is less important, because clients don't use it unless
 they have UseMicrodescriptors 0.

 When we put all the microdesc_t and routerstatus_t fields in the node, we
 can stop allocating any routerstatus_t and microdesc_t. (Or just allocate
 them on the stack during parsing.)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27248#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs