| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As with the tor-chanmgr code, the circuit manager is now implemented
using an AbstractCircMgr type that uses traits to abstract the
particular behavior of other types that it uses. (Specifically:
circuits, building circuits, and telling whether one circuit usage
is compatible with another.) Abstracting out the dependencies in
this ways makes it possible to test the circuit manager without
having to actually build real circuits.
This commit also introduces new behavior for handling pending
circuit requests. Upon getting a new request, first we check to see
if there's an existing circuit we can use. If there isn't, we look
for pending circuits and wait for them. If there aren't any pending
circuits we can use, we launch one or more, and wait for them.
So far, that's the same as the old behavior. But here's a change:
if, while we are waiting for some pending circuits, a different
circuit is completed, and it's one we could use, then the task that
was building _that_ circuit will tell us: "please look at this
circuit". This gives us better changes of getting a usable circuit
fast.
Minor changes:
* The Error type in CircMgr no longer uses anyhow; several errors
have been simplified.
* We've gotten more formal about the relationship between circuit
usage and target usage.
|
| |
|
|
|
|
| |
This would have saved ahf and me a lot of confusion in debugging a
situation where we were cloning a reference of a type that didn't
implement Clone.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is a somewhat obnoxious change in its scope and requirements,
but it makes it easier to understand what the real public and
private parts of our APIs are.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Since these parts are testing-only, let's take steps to make sure we
don't ship them in production by accident.
|
| | |
|
| |
|
|
|
|
|
|
| |
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).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This is a big change, but it is a step towards our goal of removing
tor_rtcompat:: calls directly.
|
| |
|
|
| |
This lets us simplify tor-dirclient a fair bit. Closes #79.
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously we read too much data from our input, and then used the
unused portion as an initial state of a buffer for handling
subsequent data. Yuck! Instead we can just use an AsyncBufRead and
only read the parts we want.
This code takes some pains to never read too much data: I'd rather
just "read until the first CRLF" or have some kind of pushback
mechanism. But for now it's probably fine.
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
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)
|
| | |
|
| |
|
|
|
| |
This lets us reinstate the code in dirclient that retired circuits
depending on the error type.
|
| |
|
|
|
| |
Also, remove references to DataStream, and comment on the future of
the module.
|
| | |
|
| | |
|
| |
|
|
| |
This way tor-dirclient doesn't need to link to the compression crates.
|
| |
|
|
|
| |
The related data structures are marked as public in the
tor-decompress crate so that tor-dirclient can access them.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |\ |
|
| | |
| |
| |
| | |
Adds dependency to zstd crate.
|
| |/ |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
| |
(There are more cases that this _doesn't_ handle, but it's a start
for now.)
|
| |
|
|
|
|
|
|
| |
This adds two timeouts in total: one for sending begin, and getting
headers, and one for getting the rest of the data.
These timeouts are way too long right now, but at least the code is
there.
|
| | |
|
| | |
|
| | |
|
