Opened 12 years ago

Closed 7 years ago

Last modified 7 years ago

#535 closed defect (fixed)

servers should support hearing "not new descriptor"

Reported by: arma Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: arma, nickm, Sebastian Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by nickm)

Directory authorities, when they get a descriptor that isn't new enough
(more than cosmetically different) right now send back a 200 response code.

We should send some different code, so servers have a chance of knowing
whether their uploaded descriptor actually "took" or was silently discarded.

So, changes as I understand them:
A) Tor servers should accept 200-299 as successes, not just 200.

B) What success code, within the range 201-299, most closely resembles
"I accepted it but it wasn't new enough so I didn't use it"? Is there
any precedent to follow here?

C) Once step A is done, authorities can start sending back other codes.

D) Is there any way to speed up reaching step C?

E) Should we also change 400 to a range 400-499?

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (13)

comment:1 Changed 12 years ago by arma

As for question D: we could look at the Tor version claimed in the descriptor,
and then know whether they'll be able to handle the new response codes. That
way we can start using this stuff much more quickly.

comment:2 Changed 12 years ago by nickm

For D: We can add a header in the directory response, starting *now*. Existing servers won't object to seeing
(say) X-Server-Is-Not-New.

comment:3 Changed 12 years ago by arma

Ok. B, C, and D should be solved by Nick's suggestion of using a new http
header to describe what variation on 200 we meant.

A and E remain as separate questions. Any reason not to make clients flexible
enough to know what class of response was sent, in case down the road we find
another situation where an already-defined RFC response code matches what we
mean to say? The behavior I would imagine is to treat 201-299 the same as 200
(silently be happy), and to treat unrecognized 4xx's as the same as 400 (log
to the user that "we just got a 4xx; please correct").

comment:4 Changed 12 years ago by nickm

I've checked in a partial implementation of the "new http header" solution: authorities generate the new header,
and servers notice it, but (so far) don't do anything with it.

comment:5 Changed 9 years ago by nickm

Description: modified (diff)
Milestone: post 0.2.1.xTor: 0.2.3.x-final

Marking for 0.2.3.x-final.

comment:6 Changed 8 years ago by rransom

Milestone: Tor: 0.2.3.x-finalTor: 0.2.2.x-final
Parent ID: #3327
Priority: minorcritical
Type: enhancementdefect

This is the only way to fix #3327 (and #1810).

I suggest that we add an ‘on-response’ callback parameter to every function that launches a directory request, and use that callback to update a ‘last descriptor upload time’ global variable iff the new descriptor was accepted.

comment:7 Changed 8 years ago by nickm

Priority: criticalmajor

If we want this in 0.2.2.x, the changes need to be MUCH MUCH smaller than adding new callbacks, changing interfaces, etc. We already have the code in connection_dir_reached_eof that gets called on every response from the dirserver. I'd like to change the architecture, but not for 0.2.2.

So, what's the correct actual behavior here?

We want to remember, for each authority, the 'published' time of the last descriptor that it accepted from us. We want to have another global in router.c, something like "desc_clean_since", that remembers the last time that we had our descriptor accepted by sufficient authorities. We can then replace "mark_my_descriptor_dirty_of_older_than" with a new function that declares the descriptor to be dirty if it is too old, OR if too much time has passed since sufficient authorities accepted one of our descriptors.

Or another option is to look at the publication time for the version of our descriptor that's listed in the directory consensus. This could probably use some pseudocode. Also, it feels like something to do as a branch that gets merged first to 0.2.3.x for testing, then back to 0.2.2.x: none of the solutions here feel as obvious and straightforwardly harmless as I'd want.

comment:8 Changed 8 years ago by nickm

I uploaded a fix for #3327 that should make a fix here unnecessary; please review the branch mentioned in that ticket.

comment:9 Changed 8 years ago by nickm

Can we close this now that #3327 is merged? Instead of hearing "not new", servers now upload more frequently when they do not appear in a consensus, or when the version of their descriptor listed in the consensus is very old.

comment:10 Changed 8 years ago by nickm

Parent ID: #3327

comment:11 Changed 7 years ago by nickm

Milestone: Tor: 0.2.2.x-finalTor: unspecified

I am going to be cowardly and throw this into Tor: unspecified; but really I think we could close it.

comment:12 Changed 7 years ago by nickm

Resolution: Nonefixed
Status: newclosed

It's been 13 months! Closing this.

comment:13 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.