These lints force us to declare our exported enums and
exhaustive-looking structs as non-exhaustive (so that we can add to
them in the future without breaking our API) or to explicitly
disable the warning for a given enum/struct (to say that we _intend_
for additions to be a breaking change).
The big idea of this revision is to separate the code that knows
about doing downloads from the code that decides what to download.
Later, we can make a similar change for database access. With these
changes together, we can make our code much more testable, and
eventually enable more download types in parallel.
Since we moved to a non-async mutex(*), we no longer need to worry that
this function might need to suspend.
(*) This is _not_ safe in general, but it's okay in this case, since
we never suspend while holding that mutex: see shared_ref.rs.
Doing this will make it easier to use it from other parts of the
crate, and will make it more obvious that it's safe to use a regular
(not async) rwlock here.
This will let us use these types both as client and server-side
implementations.
Making this change required me to change the download code to take
requests by reference. (Sorry, David)
A directory manager can now launch or run in read-only or read-write
mode, depending on whether it manages to acquire a lock on the
filesystem.
In read-write mode, it bootstraps and stores data into the database
as usual.
In read-only mode, it assumes that another process will be updating
the database, and so it only loads it periodically, looking for new
information. However, it also tries to acquire the lock itself, so
it can enter read-write mode.
dalek-crypto is stuck on rand_core 0.5.1, so we've been stuck too.
This commit introduces a compatibility module so that we can wrap
new rand_core instances to make them backward compatible.
This is fairly ugly and I think I'll need to mess around with the
feature configuration a while until we get something that's pleasant
to develop with. This still seems like a good idea, though, since
we _will_ need to be executor-agnostic in the end, or we'll have no
way to handle wasm or embedded environments.
Later down the road, we'll probably want to use futures::Executor or
futures::Spawn more than having global entry points in
tor_rtcompat. That would probably make our feature story simpler.
Tokio is the default now, since tokio seems to be more heavily used
for performance-critical stuff.
This patch breaks tests; the next one will fix them, albeit
questionably.
This commit adds configuration options for these values, with the
right defaults, and uses those options instead of built-in functions
to set them.
We also remove the function to extract information from chutney
directories: now that arti is configurable, it can be chutney's job
to make its own network configurations.
With this patch we don't consider a consensus to be even potentially
well-signed if the authorities that are listed as signing it don't
contain enough authorities we believe in. Otherwise, we'd just try
fetching certs for them and failing forever.
(I found this by switching from a chutney network to the main
network without cleaning out my cache.)
Closes#44
This makes a whole lot of our code simpler, and makes it so that
CircMgr and DirMgr no longer need to have anything parameterized
over transports, either.
Instead of boxing Transport inside of ChanMgr, I've made a new
Connection trait that goes from a ChanTarget* straight to a Channel.
This lets us avoid having to box the intermediate TLS object.
[*] Actually, a copy of the information from a ChanTarget. Ick, but
I had to make a copy to avoid parameterizing
Connecter::build_channel.
This follows a three-phase process: We are either fetching
microdescriptors, waiting for the time to download the next
consensus, or fetching the next consensus and making it usable.
We can stop fetching microdescriptors for two reasons: by having no
more mds that we need to download, or by running out of time in
which the current consensus is usable.
Nick Mathewson
David Goulet
George Kadianakis