| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
We need to do this so that we can actually invoke RPC functions
from one another.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
Now that Method::Error exists, we can downcast Any to the actual
function's return type.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is needed so that we can cast special methods' return types
properly.
I wish I could make this optional, but Rust doesn't allow
defaulting an associated type.
|
| | | |
| | |
| | |
| | | |
A @special invoker does not get an RPC entry.
|
| | | |
| | |
| | |
| | |
| | | |
Now Methods can return anything; and only if their outputs are
Serialize will they implement RpcInvocable.
|
| | | |
| | |
| | |
| | |
| | | |
RpcInvocable will only be implemented on types whose output
can be serialized.
|
| | | |
| | |
| | |
| | | |
This is part of work on #1403.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This will allow us to create dispatchable methods that are only
invoked from inside the arti code, and are not themselves
serializable.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
tor-circmgr: Replace STUB/STUB+ terminology with SHORT/EXTENDED.
Closes #1339
See merge request tpo/core/arti!2161
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The previous STUB/STUB+ terminology was confusing, because STUB and
STUB+ are both "circuit stubs" (but STUB is shorter than STUB+).
Closes #1339
|
| | | | |
| | | |
| | | |
| | | | |
Part of #1339
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | | |
proto: Explicitly enforce maxima on SENDME windows.
See merge request tpo/core/arti!2150
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
No actual bug here, just technical debt:
For `SendWindow`s, our tag system already ensured that we rejected
any SENDME that didn't correspond to an appropriate drain. Still,
it doesn't hurt to check.
For `RecvWindow`s, it would have been a protocol violation if we
ever did this, but it makes sense to make it an internal error if we
try.
Part of #1383.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
RPC: Enforce method name format.
Closes #823
See merge request tpo/core/arti!2149
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
(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.
|
| | |/ |
|
| | | |
|