[tor-bugs] #22781 [Core Tor/Tor]: hs: Unify link specifier API/ABI

[Tor Bug Tracker & Wiki]

#22781: hs: Unify link specifier API/ABI
---------------------------------------+-----------------------------------
 Reporter:  dgoulet                    |          Owner:  dgoulet
     Type:  enhancement                |         Status:  needs_revision
 Priority:  Medium                     |      Milestone:  Tor:
                                       |  0.3.3.x-final
Component:  Core Tor/Tor               |        Version:
 Severity:  Normal                     |     Resolution:
 Keywords:  tor-cell, tor-relay, ipv6  |  Actual Points:
Parent ID:  #24403                     |         Points:  1
 Reviewer:  teor                       |        Sponsor:  SponsorV-can
---------------------------------------+-----------------------------------

Comment (by dgoulet):

 Replying to [comment:7 teor]:
 > What about CREATE[2] cells?
 > extend_info_t is used for them, too.

 Right the goal would be to put the "link specifier" generic object in
 `extend_cell_t` leaving also the `create_cell_t` in there.

 > I'm all for avoiding premature optimisations.
 > Let's define accessor functions that do the zero-checks and then profile
 CPU and RAM.
 > Then we can add flags, and profile again.

 Sounds good. Simple first!

 > The Prop224 spec says that we should pass on all link specifiers, even
 unknown link specifier types.
 > So I think we need a final member `extra_spec_list` that's a smartlist
 pointer.
 > On the fast path, it doesn't get used, because it's NULL.
 >
 > This could handle extra addresses, too, if we ever did that.

 Hmmm well the generic object I'm talking about is the one we decode to and
 encode from `link_specifier_t` which means that if you don't recognize
 one, you ignore. Thus the object doesn't really need to keep "extra
 unknown specifier(s)" because you can really decode and encode what you
 don't know.

 This is more a matter of ignoring unknown link spec type.

 >
 > > My original branch (`ticket22781_032_01`) has already some work
 started there with `lspec_t` being a generic higher level object that
 encodes to a `link_specifier_t` and vice versa. However, it would need to
 contain all the possible links.
 > >
 > > Am I on a path that we like?
 >
 > I like this idea.
 >
 > I think this makes it easier to push all the details of choosing
 addresses deep down the stack. Then we can choose the remote address just
 before we go to connect to it. It makes a whole lot of code much easier,
 and much more generic. And we can finally implement tickets like #6772,
 and try another ORPort if the first one fails.

 Great! I'll get to it asap! Thanks for the feedback teor!

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