| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
(We don't give an error about unrecognized namespaces (for now),
since we have no way to opt in to them.)
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We need to do this carefully, since we want our system to be
extensible with new namespaces.
First, when we are constructing an RpcMgr, we _warn_ about any
method names that are misformed.
Second, we add a test in the `arti` crate to fail if any method
names are invalid. This will only catch method names in crates that
`arti` depends on.
|
| | |/ / /
| | | |
| | | |
| | | |
| | | | |
Specifically, we want a single colon, and we want our
method names to be in snake_case.
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | | |
doc: Use locked build
See merge request tpo/core/arti!2157
|
| | | | | |
|
| |\| | | |
|
| | | |/
| |/|
| | |
| | | |
Co-authored-by: gabi-250 <[email protected]>
|
| | |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
tor-circmgr: If necessary, extend the circuit to become STUB+.
Closes #1400 and #1409
See merge request tpo/core/arti!2145
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
We will soon need to reuse this.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I am about to reuse one of these on the "lite" vanguards branch. I am
renaming them to make it easier to see which one of the two I will be
using.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
One of these assertions currently fails, because we have a bug in the
vanguard path builder: if lite vanguards are enabled, we only build
2-hop circuits instead of 3.
|
| | | | |
| | | |
| | | |
| | | | |
Closes #1400
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We're about to use this in `maybe_extend_stub_circuit` too.
Part of #1400
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Per comments on #1383, we're keeping these methods.
This commit replaces the "TODO" comments with comments explaining
why it's okay that this methods are unused.
Part of #1383.
|
| | |\ \
| | | |
| | | |
| | | |
| | | | |
RPC: Allow SOCKS applications to create streams.
See merge request tpo/core/arti!2143
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The problem was that Rust won't let us say
```
type ConnTarget<R> = Arc<dyn ClientConnectionTarget>;
```
because the R parameter wasn't used.
Previously we solved this by using a macro instead of a type
definition, which is ugly.
I had been thinking previously I would need to declare some kind of
additional wrapper type, and had shrunk from the verbosity. But
@diziet pointed out that I could just use a 2-tuple unconditionally.
It's still not beautiful, but it is less hideous than before.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Document its relation to the method system, and possible future
evolution.
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
Also, improve documentation.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
(This is a separate commit to make the branch more readable)
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The application creates these, using a new-stream-handle RPC command,
on an object that can actually create streams.
Then later, the application provides the (global) identity of one of
these objects when it's making a SOCKS connection. This causes the
object to take hold of a `DataStreamCtrl`.
|
| | | |/
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
(These will later become objects that can receive any application
request, once we have HTTP connect.)
For now, Session and TorClient implement this trait;
but soon there will be a new type to hold on to the created
DataStreamCtrl.
There are some XXXXs here, marking code that is too ugly to live.
I should fix it before I merge this branch.
|
| | |/ |
|
| | | |
|
| | |\
| | |
| | |
| | |
| | | |
RPC: Preliminaries for RPC-stream integration
See merge request tpo/core/arti!2140
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Instead, add a trait so that we can hold TorClient<R> and invoke
only the methods on it that we need.
This is a partial revert of 47f012829d3381fd896c6b6f20961fbfe2f40f6d.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Previously we could only downcast to &dyn Trait,
which is not adequate.
|
| | | |
| | |
| | |
| | |
| | | |
This makes `ObjectRefExt` less necessary, and will let us make it
Arc-only.
|
| | | |
| | |
| | |
| | | |
I think I'm going to add another stream management module here.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This change allows it to hold a TorClient<R> that isn't type-erased.
We'll use this for cases when we need to get the client directly
and call functions on it.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |\ \
| | | |
| | | |
| | | |
| | | | |
tor-guardmgr: Address some vanguard-related TODOs
See merge request tpo/core/arti!2139
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
I don't think it's all wrong, this was left over from the first draft
implementation.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously, `select_vanguard` returned a `NoSuitableRelay` error if
it was unable to select a relay to use as a vanguard.
We now distunguish the "there are no suitable relays in the vanguard
sets" (`NoSuitableRelays`) error case from the "our vanguard sets are
empty" (`BootstrapRequired`) one.
|
| | | | | |
|