Never send a consensus which the downloader already has

FWICT, we have a regression in our new consensus code: we no longer check the if-modified-since date when serving consensuses, since that field isn't set in the consensus_cache_entry_t case of .

Additionally, if somebody says X-Or-Diff-From the consensus which we currently have, then instead of telling them "That's up-to-date", we also send the current consensus. That's also bad.

These problems make the most trouble in test networks, where the consensus update rate is so fast that relays frequently try to download a consensus before it's there.

Diagnosed with help from ahf.

changed milestone to %Tor: 0.3.1.x-final

added actualpoints::3 component::core tor/tor directory milestone::Tor: 0.3.1.x-final owner::ahf points::3 priority::high regression resolution::fixed severity::normal sponsor::4 status::closed tor-relay type::defect labels

Trac:
Status: new to assigned
Owner: N/A to ahf

Additionally, if somebody says X-Or-Diff-From the consensus which we currently have, then instead of telling them "That's up-to-date", we also send the current consensus. That's also bad.

What is meant here by "which we currently have"? Prop#140 allows a client to send multiple hashes of the consensuses they have, but our current request sending code only ever sends one hash, but our request receive path handles multiple hashes (which is according to the proposal).

Should we check if the digest_sha3_as_signed (from networkstatus_t) in our currently "live" consensus document, of the given client requested flavour, matches any one of the set of hashes the client sends to us in the X-Or-Diff-From-Consensus header - or should we only handle the case where a client sends one hash that happens to match the digest_sha3_as_signed? Or something entirely different?

I'm tracking this issue in https://gitlab.com/ahf/tor/commits/wip/22702

Replying to ahf:

Additionally, if somebody says X-Or-Diff-From the consensus which we currently have, then instead of telling them "That's up-to-date", we also send the current consensus. That's also bad.

What is meant here by "which we currently have"? Prop#140 allows a client to send multiple hashes of the consensuses they have, but our current request sending code only ever sends one hash, but our request receive path handles multiple hashes (which is according to the proposal).

If they include a hash that indicates that they would accept a diff from the most recent consensus, then they have the most recent consensus, and we should not send it to them.

Should we check if the digest_sha3_as_signed (from networkstatus_t) in our currently "live" consensus document, of the given client requested flavour, matches any one of the set of hashes the client sends to us in the X-Or-Diff-From-Consensus header - or should we only handle the case where a client sends one hash that happens to match the digest_sha3_as_signed? Or something entirely different?

I think it's an "any" condition: if they say they have the most recent consensus, we shouldn't send them any diff.

Great. I'll implement that on top of the current patch and restart the measurement - should give us enough data by tonight (UTC).

I've two patches up for review in https://gitlab.com/ahf/tor/merge_requests/17/commits

Trac:
Status: assigned to needs_review

Requested a function rename.

Also, this needs a changes file.

Trac:
Status: needs_review to needs_revision

I've added a fixup commit and added a changes file.

Trac:
Status: needs_revision to needs_review

Looks good, except that this branch was based on master. Next time you're fixing a bug on 0.3.1, remember to base it on maint-0.3.1.

This time, it rebased cleanly. I've squashed and rebased as ahf_bugs_22702_squashed, and I'm merging it to maint-0.3.1 and forward. Thanks!

Trac:
Resolution: N/A to fixed
Status: needs_review to closed
Points: 1 to 3

Trac:
Actualpoints: N/A to 3

closed

changed time estimate to 24h

added 24h of time spent

moved to tpo/core/tor#22702 (closed)