#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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs