Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #11428

Closed (moved)
Open
Opened Apr 07, 2014 by Karsten Loesing@karsten

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

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 (moved).

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.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#11428