[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 dgoulet):

 Replying to [comment:4 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).

 +1 on this idea.

 I *think* (to be verified), that dirauth might need to have this
 separation concept in order to publish that information but also to create
 the consensus. In other words, iirc, when receiving for instance a new
 microdescriptor from a relay, the code then tries to find differences
 (cosmetic or not) from the previous one.

 So for dirauth, keeping those objects separate makes things I guess easier
 code wise. Again, not entirely sure.

 Anyway, overall, I strongly agree that `node_t` could keep only the
 required field for which a lot of them appear in all 3 objects but also
 I'm guessing some fields are also probably only useful for dirauth.

 There is a concept of mutable vs immutable with these objects within a
 `node_t` object though but we can figure that part easily and even create
 a way better/clearer/safer model for that part.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/27248#comment:5>
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