Skip to content

Define and implement a backend padding API, based on maybenot.

Nick Mathewsonrequested to merge
nickm/arti:maybenot-backend into main

There are incomplete pieces, marked with "TODO circpad".

There is no integration into the circuit reactor code yet.

Part of #63.

For the reviewer: This branch wraps the maybenot padding framework to support an API that matches Tor's needs better. Events are passed into the framework via function calls to a PaddingController; actions that the circuit needs to take are returned in a PaddingEventStream.

I'd suggest starting out by scanning the maybenot documentation. There are unreleased improvements there, so I've linked to a version of the docs built from the latest main.

One wrinkle to consider (after the maybenot docuemtation) is that we actually need multiple padding instances per circuit, since we need to support padding independently to and from any hop.

Then I'd review the code from the lowest to the highest level:

  • First padding.rs. It has some top-level documentation for the design as a whole.
  • Then backend.rs. This is the lowest-level part. It wraps maybenot::Framework and implements most of the state code boilerplate we need to keep track of the state for a single hop's padding.
  • Then maybenot_padding_rs. It aggregates several of those wrappers into a single structure for an entire circuit, and exposes PaddingController and PaddingEventStream with multi-hop support.

Notes on the design:

  • I'm trying to keep the allocations manageable by using SmallVec to inline structures where it seems reasonable to do so. We'll want to tune this some more; any refactoring should be very self-contained to the padding module.
  • I've probably over-optimized things in some cases, and under-optimized in others. If it's all right, I'd like to defer (un)optimizing a little while until we have integration farther along. (But please feel free to let me know where you think we should (un)optimize immediately!)

Merge request reports