GitLab

Let each resource type specify dist proportions

Closes #37

See merge request !10

Modify the configuration file to allow each resource type to specify
their own distribution proportions. If no distribution proportions are
specified, the default distribution proportions are used.

Add dummy distributor for educational purposes.

Closes #33

See merge request !9

This patch adds a dummy distributor (and corresponding documentation)
that does the bare minimum to fetch resources from the backend and
distribute them over a Web API.  The dummy distributor has two benefits:

1) It helps newcomers understand the interaction between a distributor
   and the backend.

2) It can serve as a template to speed up the process of implementing a
   new distributor.

This fixes #33.

Issue/5

See merge request !8

Our persistence mechanism is used by a distributor's user-facing
presentation layer.  When the presentation layer starts, it uses the
persistence layer to load (and later save) data that needs to persist
across restarts.

To make gob work, this patch also turns mutexes from an embedded type or
uppercase member into a lowercase member.

Add documentation on how resources are tested.

Closes #31

See merge request !7

This fixes #31.

Issue/30

Closes #30

See merge request !6

So far, if rdsys was unable to talk to bridgestrap, it would accumulate
goroutines for pending test connections until rdsys eventually failed
due to an out of memory exception.

This patch fixes the problem by refactoring the API that talks to
bridgestrap and by not adding resources to the test pool if they're
already being tested.

This fixes #30.

In particular, we export the following metrics:

* Number of API calls for each endpoint.

* Total number of resource types at any point in time.

* Fraction of untested/functional/dysfunctional resources per resource
  type.

The metrics will be available at the /rdsys-backend-metrics.

This patch fixes #14.

...cause that's how Tor likes 'em.

Issue/29

Closes #29

See merge request !5

We shouldn't blindly take whatever transports we can find in a bridge's
extrainfo descriptor.  Some bridge operators even set up a meek
transport and we don't want to distribute those.

This patch fixes #29.

This patch implements the following two improvements:

* Change ForceAdd to AddOrUpdate.  We don't want to update a resource
  unconditionally because that means that we lose its latest test.  We
  only want to update it if its object ID changed.

* Add maybeTestResource.  The method helps us be a bit smarter about
  when we want to test a resource.  If a resource's UID and OID remain
  the same *and* it's already tested *and* the test result hasn't
  expired yet, we don't need to test it.  This will dramatically
  decrease the interactions with bridgestrap.

The code was trying to be more general than is necessary.  The hook is
specifically for testing and nothing else.

Because usability is everything!

A bridge's fingerprint is confidential information because one can use
it to fetch the bridge's descriptor (which includes its address) from
Serge.  We should therefore support status lookups based on hashed
fingerprints, similar to how Relay Search does it.  That allows bridge
operators to publish their bridge's status page URL.

This patch makes it possible to look up a bridge's status based on
fingerprint *or* hashed fingerprint.  The patch also makes the lookup
slightly more robust by removing leading and trailing spaces, and
by ignoring the capitalisation of the given fingerprint.

To get this done, the patch had to change the way we determine a
bridge's Uid -- it's now based on hashed fingerprints rather than
fingerprints.

This patch fixes #28

Issue/16

Closes #16

See merge request !4

...and put it in the doc/ directory.

This patch fixes #16

All we're accepting now is the 'id' parameter, and the resulting page
shows all available resource types.

This patch fixes #26

Issue/10

Closes #10

See merge request !3

So far, we only saved a resource's state, i.e. if it's untested,
functional, or dysfunctional.  This patch makes rdsys also save when it
was last tested (according to bridgestrap) and what error occurred
during testing (if any).  This information is critical to bridge
operators who want to learn their bridge's status.

This patch partially fixes #10

Bridge operators want to find out as soon as possible if their bridge
works.  This patch implements a /status page that tells bridge operators

1. If their bridge is untested, functional, or dysfunctional.
2. When their bridge was last tested according to bridgestrap.
3. What error happened during testing (if any).

This patch partially fixes #10