Opened 5 years ago

Closed 5 years ago

#11428 closed enhancement (fixed)

Always return non-empty bandwidth and clients documents for running relays/bridges

Reported by: karsten Owned by: karsten
Priority: Medium Milestone:
Component: Metrics/Onionoo Version:
Severity: Keywords:
Cc: lucyd Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Bandwidth documents are based on bandwidth histories contained in extra-info descriptors, and clients documents are based on directory request statistics contained in bridge extra-info descriptors.

There are situations when a new relay or bridge doesn't report a long-enough bandwidth history for us to write a bandwidth document. And it probably happens even more frequently that a bridge doesn't report directory request statistics, so we don't write a clients document.

The effect is that we may return a details and an uptime document for those relays/bridges, but no bandwidth or clients documents. This may confuse Onionoo clients, which last happend in #9889.

What we should do is return non-empty bandwidth and clients documents for running relays and bridges. These can contain just the fingerprint and no graph data.

Implementation change:

  • When writing a response and can't find a bandwidth or clients file, generate one on the fly that only contains the fingerprint or hashed fingerprint.

Spec changes:

  • Make write_history and read_history in bandwidth documents optional. We need to make sure that all known Onionoo clients can handle this change and don't break if these formerly required files go away.
  • While doing so, let's make uptime in bridge uptime documents optional. That will also make it consistent with relay uptime documents. This change is not directly related to this bug, but leaving this field required seems inconsistent.

Child Tickets

Change History (6)

comment:1 Changed 5 years ago by karsten

Asked on tor-dev@ and in private mail whether the suggested specification changes above will break anyone's Onionoo client. Requested feedback by Wednesday, April 16.

comment:2 Changed 5 years ago by lunar

The various periods were already not always present, so I don't think that's a big change.

comment:3 Changed 5 years ago by rndm

I checked Globe and it works with history results that don't contain read_history, write_history or uptime.
(see example https://github.com/makepanic/globe/blob/trac-11428/test/unit/trac-11428.test.js#L5-L12 )

comment:4 in reply to:  2 Changed 5 years ago by karsten

Replying to lunar:

The various periods were already not always present, so I don't think that's a big change.

Agreed. But it's still a big enough change to break applications. Hopefully this is not the case though.

comment:5 in reply to:  3 Changed 5 years ago by karsten

Replying to rndm:

I checked Globe and it works with history results that don't contain read_history, write_history or uptime.
(see example https://github.com/makepanic/globe/blob/trac-11428/test/unit/trac-11428.test.js#L5-L12 )

Great! Thanks for checking!

comment:6 Changed 5 years ago by karsten

Resolution: fixed
Status: newclosed

Implemented as suggested above and deployed. Closing.

Note: See TracTickets for help on using tickets.