| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Well, mostly correct. Our current serde implementation doesn't
tell us much about what went wrong with the object, so we can't
tell why we couldn't convert it into a Request.
Also, our output for the data field is not as the spec says:
we should bring them into conformance.
Part of #825.
|
| | | |
| | |
| | |
| | |
| | | |
These are experimental for now so that we can change them without
breaking semver.
|
| | | |
| | |
| | |
| | |
| | | |
The field is called "kinds", it is a list, and it holds strings
beginning with "arti:".
|
| | | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
ExitPath: Add an explanation of WeightRole::Exit on non-exit circs
Closes #785
See merge request tpo/core/arti!1135
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In one case, we use WeightRole::Exit on circuits that can't
actually be used to exit. This commit adds a comment to explain
why, so that we don't wonder about it in the future, and we have
some indication of whether it's still appropriate.
Closes #785
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
Remove misleading TODO.
See merge request tpo/core/arti!1130
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The `superencrypted` blob is, in fact, followed by a newline.
See [core/torspec!122].
[core/torspec!122]: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/122
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
We now _use_ the function pointers rather than comparing them; this
lets us drop our Eq/PartialEq/Hash implementations for
`ConstTypeId_` and instead just use `TypeId`s once we're in run-time
code.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
(Except for one case where we are using crate::Context and
task::Context at the same time.)
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It's experimental, and tokio-only. To enable it, build with
the "rpc" feature turned on, and connect to
`~/.arti-rpc-TESTING/PIPE`. (`nc -U` worked for me)
I'll add some instructions.
|
| | | |
| | |
| | |
| | | |
(This is what my editor wants to do to it.)
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 lets us avoid async_trait in tor-rpccmd, and makes us use a
Box<>. I think we might actually get an even smarter type later on,
but we will need to play with this for a while too.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Now the user has to say that the fn takes an
Arc<>, a Box<>, and an Arc<dyn>. Previously, they had to pretend
that it didn't.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This could have been a trait instead, but I don't know whether
that's smart or not. There is a lot of opportunity for refactoring
here.
|
| | | |
| | |
| | |
| | |
| | | |
This will let the actual RPC functions return any Result type that
we can serialize.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I'm not sure about these APIs at all! They force us to use
`async_trait` for `tor_rpccmd::Context`, which bothers me. Should we
just have a function that returns
`Option<Box<dyn Sink<Item=X, Error=Y>>` or something? If so,
what's the correct Y?
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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`).
|