| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Now there can be one of each, since we want references and handles
to be conceptually separate.
(The alternative would be to say that an operation either "returns a
handle" or "returns a reference (which may become a handle) unless a
handle already exists.")
|
| |
|
|
|
| |
This fake version is completely silly, but it will do the job until
we figure out our MPL2 concerns.
|
| | |
|
| |
|
|
|
|
|
| |
To me, "Session" suggests that we're authenticated, when we are
not necessarily authenticated. Also, we may eventually want to have
some kind of persistent session object; if we do, then we'll want
Connections to be separate.
|
| |
|
|
|
|
| |
(This is the correct capabilities-based behavior. For now it will only
work if the TorClient uses a PreferredRuntime, but with luck we will
find a solution for #837 soon.)
|
| |
|
|
|
|
| |
See the comments on `TypedAddr` for some explanations about
why this is so tricky. Thanks to @diziet for helping me figure
this out.
|
| | |
|
| |
|
|
|
| |
Because of #837, we won't be able to work with _every_ TorClient<R>,
so I'm only going to be using TorClient<PreferredRuntime> for now.
|
| |
|
|
|
|
|
|
|
| |
Now there's a module in `arti` that runs the loop for an RPC
listener. The part of the old `listener` module that made
the framed connections is now part of the `Session` object.
There is now yet another a temporary location for the pipe; we
should pick something better. At least now it's configurable.
|
| |
|
|
|
|
|
|
|
| |
In the future, this will probably hold more data as well, like a
TorClient and some configuration info.
The TorClient will present an issue; I've made comments about that.
Closes #820
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Right now, this lets us say whether the method was unrecognized or
whether the parameter type was incorrect.
We'll use this to enforce correct method names later on.
(I have to add another `inventory` here, since the `typetag`
maintainer does not want to expose this functionality: see
https://github.com/dtolnay/typetag/issues/57#issuecomment-1506106290
)
|
| | |
|
| |
|
|
| |
This lets us do much less in our rpc_invoke_fn functions.
|
| |
|
|
|
| |
Now `Method` has an Output and Update associated type, and
`decl_method` can do a little more.
|
| |\
| |
| |
| |
| |
| |
| | |
A few RPC refactorings
Closes #817 and #824
See merge request tpo/core/arti!1144
|
| | |
| |
| |
| |
| | |
Previously we have two places where we had to do "make a `Drain` sink
if updates aren't wanted"; now there's only one.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously the main loop received updates via a `mpsc::channel`, and
final responses via a `futures::unordered`. This could lead to
final responses being transmitted to the user before the updates
were all flushed.
Now all of the responses are sent to the main loop via the same channel,
and they can't get out-of-sequence.
Closes #817 and (IMO) simplifies the code a bit.
|
| | |
| |
| |
| |
| | |
Now the update sink is its own boxed object. It is not yet passed
to the invoke functions that want it.
|
| |/ |
|
| |
|
|
|
|
|
| |
Now instead of hoping that buggy clients will detect a magic `id`,
we can simply tell them that they will get no `id` at all. If they
can't handle that case, no major harm is done: the connection will
get closed anyway.
|
| |
|
|
|
|
| |
Since we're serializing everything in this format, let's enforce it.
With this change, we can no longer cram arbitrary junk into an
RPC error, so we have to clean up our handling of cancelled requests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bit big, but it's not that _complicated_.
The idea here is that we use serde's "untagged" enum facility
when parsing our `Request`s, such that if parsing as a `Request`
fails, we parse as an `InvalidRequest` and try to report
what the problem was exactly.
This lets us determine the ID of a request (if it had one),
so we can report that ID in our error message. We can also
recover from a much broader variety of errors.
We now also conform with the spec reporting errors about
completely wrong json, requests without IDs, and so on.
|
| |
|
|
|
|
| |
Even though json-rpc uses "result" to mean "a successful return value
from a method", we can't: Rust's `Result` type is so pervasive
that confusion would be inevitable.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
(Except for one case where we are using crate::Context and
task::Context at the same time.)
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
Per our design, every connection starts out unauthenticated, and
needs one authenticate command to become authenticated.
Right now the only authentication type is "This is a unix named
socket where everybody who can connect has permission."
|
| |
|
|
|
| |
It requires tokio, it's unix-only, and makes some unfortunate
shortcuts. Probably good enough for initial testing.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This code uses some kludges (discussed with Ian previously and
hopefully well documented here) to get a type-identifier for each
type in a const context. It then defines a macro to declare a
type-erased versions of a concrete implementation functions, and
register those implementations to be called later.
We will probably want to tweak a bunch of this code as we move ahead.
|
| |
|
|
|
| |
This crate will hold the backend pieces of RPC interaction that
different parts of Arti get to implement.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Ordinarily you can cancel a future just by dropping it, but we'll
want the ability to cancel futures that we no longer own (because we
gave them to a `FuturesUnordered`).
|
