| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit removes the separate function for asking whether to
bypass the dispatch code. Instead, it gives the "invoke with
bypass" function an error to return when no dispatch is warranted,
and moves the whole responsibility for method dispatch or
non-dispatch back into tor-rpcbase.
I had to add an ObjectId argument to `invoke_rpc_method` to make
this work, but that's probably a good thing.
Additionally, this commit tweaks the derive-deftly macro to prevent
you from asking for dispatch bypass on special methods, where it
isn't implemented (and doesn't really make sense).
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Our spec says that when the RPC client has said "I require you to have
feature X" and we don't have it, we need to include the feature(s)
we don't have in an `rpc:unsupported_features` field of our error.
Also, add an integration test for this behavior.
Closes #1662
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
These are not regular ErrorKinds, since they can never occur in an
error that's meant to be returned from a Rust API like
`arti-client`. Instead, they only exist for errors returned from
RpcError.
(I can't find the place where we discussed this previously, but the
rationale is that if an ErrorKind never makes sense in response to
something that the user does from Rust, we should never have that be
an ErrorKind. The fact that the removed kinds do not actually
appear outside the RPC system suggests that this is reasonable.)
|
| |
|
|
|
| |
We need to decide whether RPC will participate in memquota.
Perhaps it should. But that's for the future.
|
| |
|
|
|
|
|
|
|
|
| |
We have defined a forward-compatibility mechanism for the RPC
system, where a request may list one or more required "features",
and if any feature is absent, the request will fail.
Since no "features" are currently implemented,
this code does the bare minimum to implement this mechanism,
by rejecting every request with a nonempty "require" field.
|
| |
|
|
| |
Based on review from @opara.
|
| |
|
|
|
|
| |
Previous documentation was more-or-less meant for the Arti developer
only. This new documentation is intended for actual users of RPC
functionality. It's meant to be extracted with `maint/rpc-doc-tool`.
|
| | |
|
| |
|
|
|
|
| |
I've used an `async{ expr }.await` pattern, to make sure that
_every_ error returned by the `loop{select!{}}` construct is
actually transformed.
|
| |
|
|
| |
(This will make the next commit easier to read.)
|
| | |
|
| |
|
|
| |
Per suggestion from @diziet.
|
| |
|
|
|
|
| |
Instead of classifying errors and complicating our behavior _early_
in our loop, instead we just decide whether an error indicates an
EOF immediately before we return it.
|
| |
|
|
|
|
| |
Make it more clear than the previous match statement
that once we get an Err() from request_stream.next(),
we aren't going to continue the loop.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, after determining that an error on an RPC connection
was fatal, we would:
1. Determine whether it was a "clean" close or one
that needed to be logged.
2. In exactly one case (specifically, when the inbound Json stream
contained a Value that was not an Object) , we would send back a
message to the client.
3. Exit the connection with Ok() or Err(e).
We no longer do step "2" above.
Additionally, we document:
- Why it's important to exit immediately on syntax errors.
- A better way to tolerate non-Object Json Values,
if we decide someday to do so.
Closes #1591.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In general, we don't want to return a ConnectionError for a simple
EOF condition; we only want to report an error when there's an
actual failure.
Also, it's a good idea to capture the actual error return conditions
that we get from aynchronous_codecs, rather than throwing them away
as we did before.
Closes #1517.
|
| |
|
|
|
|
|
|
|
|
|
| |
This lets us get rid of a now-spurious `RequestContext` wrapper type
and an extra layer of indirection; it will also make it easier to
treat a Connection _as_ a context, so that we can have a context in
the socks-rpc interface code.
This patch removes a TODO about "treading carefully" when we make
this change. When I added that TODO, I had misremembered some
implementation details of the RPC object system.
|
| |
|
|
| |
This will allow us to implement rpc::Context on Connection directly.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Formerly we used a Box. That was okay at first, but now that we
want RPC methods to be able to invoke other RPC methods, we don't
want the Invocable methods to have to consume the Context.
This requires that Context become Sync.
|
| |
|
|
|
| |
We need to do this so that we can actually invoke RPC functions
from one another.
|
| |
|
|
|
|
| |
This will allow us to create dispatchable methods that are only
invoked from inside the arti code, and are not themselves
serializable.
|
| |
|
|
| |
I think I'm going to add another stream management module here.
|
| |
|
|
|
|
|
|
|
| |
We don't actually need this to be a trait; we just need
methods and objects to have a `CONST_TYPE_ID_` if they want to
participate in the inventory-based method registry.
Removing this trait makes it much simpler to declare methods and
objects.
|
| |
|
|
|
|
| |
This simplifies our implementation logic in a few places,
and simplifies our invocation syntax greatly. There are a few
infelicities, noted in `TODO RPC` comments.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This will later let us tell the session-creation function
how the authentication occurred, which will let it decide
what privileges to provide.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Formerly, every time we wanted to launch a new connection, we had
to give the RpcMgr a TorClient. The connection would hold that
TorClient until a session was authenticated, and then would wrap
it in a Session and put it in the object map.
Now, the RpcMgr holds a Box<dyn Fn()...> that knows how to
create Sessions. When a connection is authenticated, it
asks the Mgr to make it a new session. This lets us make it
clearer that the TorClient simply can't be given out until the
connection is authenticated. Later, it will let us create
more types of Session objects under more complicated rules.
|
| | |
|
| |
|
|
|
|
|
|
| |
This adds a Weak reference from Connection to Mgr, makes DispatchTable
mutable, and makes a few other changes as discussed between me and
Diziet the other week.
I bet we are not done tweaking this, but I hope it's a setp forwards.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
These identifiers are actually only "global" with respect to a given
`RpcMgr`, but they should not be forgeable or reusable across RpcMgr
objects. We're going to use them so that we have a kind of identifier
for `TorClient`s that we can expose to SOCKS.
|
| | |
|
| |
|
|
|
| |
We're going to use this to implement arti#863, which requires that
some RPC objects be globally nameable.
|
| |
|
|
|
|
|
| |
Rationale: Our weak-vs-strong design is a bit confused at the moment
due to concerns about deduplication and capability semantics. It's
not clear that a general "change strong to weak" method is
compatible with what we want to provide.
|
| |
|
|
|
|
|
|
|
|
|
| |
I've made doing some design choices here:
* Reserving "rpc" as a prefix for post-authentication
functionality that is not arti-specific.
* Declaring these to be methods on the session rather than methods
on the objects themselves.
There's a problem with defining an API to drop a weak reference; see
comment in code.
|
| |
|
|
|
|
| |
This will make it easier to change the semantics of what exactly we
return, whether it has to be/contain a client, whether you can use
it to look up all the live objects, &etc.
|
| | |
|
| |
|
|
|
| |
These are about to become nondeterministic-ish and probably shouldn't
use the Into/TryFrom traits.
|
| | |
|
| |
|
