GitLab

Issue/6

Closes #6

See merge request !2

This patch fixes #6

...and start with version 0.0.1.

If our event channel is closed, our last read results in nil.  This
patch makes bridgestrap check for this condition before accessing the
result's struct members.

We can safely ignore http.ErrServerClosed but we really ought to check
for other errors.

Issue/3

Closes #3

See merge request !1

So far, bridgestrap would bootstrap a new tor instance for each request.
That's both expensive and slow.  Roger suggested to use a single,
long-lived tor instance instead, and use the SETCONF controller command
to test a batch of bridges at once.  This patch makes that happen.

This fixes #3.

Simply run:

  ./scripts/test-bridge-lines /path/to/bridge/file

The provided file must contain bridge lines, one per line.

Thanks to Cecylia for questioning whether the cache lookup mechanism is
fast enough:
ecc6e048 (comment 2709958)

We currently have ~1,700 bridges, so a buffer size of 1,000 isn't going
to cut it if we ask bridgestrap to test our entire pool of bridges at
once.

This command line option instructs bridgestrap to only pretty-print its
cache and then exit.

Unlike the Web API, we don't reject connections.  Instead, we try hard
to serve them all, even though some may be delayed.

That allows us to cache bridge lines of connections that were still open
while we received the signal to shut down.

We are GETting rather than POSTing something, and "bridge-state" is a
more descriptive resource name.

This patch also merges our Web interface and our API handlers, making
the code simpler.

This makes our API naming convention consistent with wolpertinger.

Again, we cannot use an error type here (which would be significantly
more convenient) because of the following issue:
<https://github.com/golang/go/issues/23340>

When bridgestrap tests several bridges in parallel, it spawns several go
routines.  When all these go routines access our cache simultaneously,
we're running into sync issues because more than one go routine is
reading from or writing to the cache.

This commit adds a locking mechanism to fix this issue, and a unit test
to demonstrate that the fix works.

This is way overdue.  Thanks to Simone Basso for the suggestion.

Our cache will contain hundreds of bridges.  Testing all these bridges
again after bridgestrap quits for whatever reason is expensive.  This
patch makes bridgestrap write its cache to disk when it exists, and
read it from disk when it starts, so we don't have to re-build our cache
after a restart.

The new flag '-cache' specifies the path to our cache.