[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #24767 [Core Tor/Tor]: All relays are constantly connecting to down relays and failing over and over
#24767: All relays are constantly connecting to down relays and failing over and
over
-------------------------------------------------+-------------------------
Reporter: arma | Owner: dgoulet
Type: enhancement | Status:
| needs_review
Priority: Very High | Milestone: Tor:
| 0.3.3.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-relay, tor-dos, performance, | Actual Points:
review-group-32, 033-must, review-group-34, |
033-triage-20180320, 033-included-20180320 |
Parent ID: | Points:
Reviewer: asn | Sponsor:
-------------------------------------------------+-------------------------
Comment (by nickm):
Replying to [comment:34 dgoulet]:
> Replying to [comment:31 nickm]:
> > So on the hash function: You can't use a memcpy(tor_addr_t) like that,
because some of the bytes of the tor_addr_t can be unspecified. I can fix
that up.
>
> Oh damn because of the union, if it is a v4, we'll copy bunch of uninit
bytes from the larger v6. I guess setting the size according to the family
is the way to do it.
>
> > On unable_connect_since_ts: Do we ever clear this field (re-set it to
zero) on success? It seems like it just stays set forever. If so maybe a
better name would be something like "last_failed_connect_ts"?
>
> It is a timestamp, we don't need to reset it. It always being compared
to a cutoff so even thought it is set once and never touched again, that
is fine since it will at some point always pass the cutoff.
Is it okay with you if I change the name anyway? The problem is that the
"since" implies a continuous condition. If I say "I have been unable to
eat broccoli since 1982", it does not mean only that in 1982 I failed to
eat broccoli: it also means that at every time since 1982, I have also
been unable to eat broccoli.
> > Oh, and one more thing I noticed: It is not enough to just check
"node_get_pref_orport(node, &node_addr_port);" -- the node may have
multiple addresses, and "pref" just returns the one you would prefer to
use yourself.
>
> Not sure it is a problem here. We use `node_get_pref_orport()` only to
make sure the or connection we are about to note down as a failure matches
the `node_t` we have from the identity digest. In this case, we use the
node_t to keep the timestamp. If it doesn't match (because other port/addr
for the identity), we note it down as a "unknown".
>
> This ends up to be the same result but just more precisely indexed by
addr + port + digest always.
But the preferred address can change while Tor is running, I think, based
on configuration options. That would make the value cached in the node
become incorrect, and that's why I think we should maybe just not have
this in the node_t at all.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24767#comment:36>
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