[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3786 [Tor Relay]: Make clients and bridges use their IPv6 address
#3786: Make clients and bridges use their IPv6 address
-----------------------+----------------------------------------------------
Reporter: ln5 | Owner: ln5
Type: task | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.3.x-final
Component: Tor Relay | Version:
Keywords: | Parent: #3563
Points: | Actualpoints:
-----------------------+----------------------------------------------------
Comment(by ln5):
Replying to [comment:12 nickm]:
> In extend_info_from_* , I think that use_pref_addr is the wrong name for
the argument; I think instead it should be "for_direct_connect" or
something. That way, the caller only needs to know what they want to do
with the extend_info; not what their needs imply about how the extend_info
needs to be generated.
Good point. Fixed in eed5d661.
> The test in circuit_get_open_circ_or_launch looks right to me: in the
case of a onehop circuit, the extend_info for the exit node you want
should be the one you're using to connect to it.
Great. Comment removed in eadc5594.
> If node_get_all_orports() is at all near the critical path, we should
think about some way to make it faster: allocating and freeing little
objects over and over can get expensive.
Would you suggest node_get_all_orports() taking a smartlist pointer as an
argument? And even two (optional) tor_addr_t pointers?
> Have a look at the callers of node_get_{prim,perf}_{addr,orport} : would
it make more sense or less sense to make these functions yield a
tor_addr_port_t instead?
Yes, that's what I intend to do next.
> In get_configured_bridge_by_routerinfo: if there is no bridge configured
with the preferred address, should we fall back and check whether there is
one configured with the primary address? Or did I misunderstand
something?
We should check "the other" address. I totally missed that.
More generally, we should check all addresses, preferring "the preferred".
> Otherwise looks okay, I think. If you think I should merge after the
next round, please include a changes file, and let me know how tested this
is/isn't at that point.
I'll squash {node,router}_get_{prim,alt,perf}_addr with their _orport
counterparts and then ask for merge.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3786#comment:13>
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