| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\
| |
| |
| |
| | |
relay: Add relay cargo feature flag and subcommand
See merge request tpo/core/arti!2182
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add the optional non default feature flag "relay" that will be used to
enable relay support of arti.
This commit also adds the "relay" subcommand to arti binary conditionnal
on the feature flag in order to have a place holder starting point.
Signed-off-by: David Goulet <[email protected]>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
RPC: Use RPC methods instead of the "ClientConnectionTarget" trait.
Closes #1427
See merge request tpo/core/arti!2192
|
| | | | |
|
| | | | |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On its own, this might not seem like a huge improvement, but it will
later let us implement these RPC methods for types that can't
reasonably implement ClientConnectionTarget.
It also serves as a proof of concept that special-method invocation
can actually work, so that we can build things like this in cases
where introducing a trait isn't practical.
Closes #1427
|
| |\ \
| | |
| | |
| | |
| | | |
RFC: Provide and use SometimesUnboundedSender in circuit reactor
See merge request tpo/core/arti!2172
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
If only I'd used a macro for these, but that's not entirely
straightforward.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |/
|/| |
|
| | |
| |
| |
| |
| | |
Every method is either "special" or not; therefore, it is always a
Bug if we look for an rpc_invoker and don't find one.
|
| | | |
|
| | |
| |
| |
| | |
The context will make it possible to invoke rpc methods.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Doing it this way will allow us to invoke methods without holding
the read lock on the table, implicitly or via the future.
I am not yet removing the methods on DispatchTable, since the tests
need them; I've added TODOs to revisit and remove later.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
The 1.2.4 release is out, so we won't be needing these anymore.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
I was unable to publish tor-memquota 0.19 because I don't have ownership
```
error: failed to publish to registry at https://crates.io
Caused by:
the remote server responded with an error (status 403 Forbidden): this crate exists but you don't seem to be an owner. If you believe this is a mistake, perh
aps you need to accept an invitation to be an owner before publishing.
```
Let's downgrade it for now.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Done using
```
(cd crates/hashx/bench && cargo update)
(cd crates/equix/bench && cargo update)
```
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Done using
```
cargo set-version -p arti --bump patch
```
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The unstable crates are:
- tor-error
- tor-config
- tor-units
- tor-geoip
- tor-rtcompat
- tor-rtmock
- tor-log-ratelim
- tor-rpcbase
- tor-memquota
- tor-llcrypto
- tor-protover
- tor-bytes
- tor-hscrypto
- tor-socksproto
- tor-checkable
- tor-cert
- tor-linkspec
- tor-cell
- tor-proto
- tor-netdoc
- tor-consdiff
- tor-netdir
- tor-relay-selection
- tor-persist
- tor-chanmgr
- tor-ptmgr
- tor-guardmgr
- tor-circmgr
- tor-dirclient
- tor-dirmgr
- tor-keymgr
- tor-hsclient
- tor-hsservice
- tor-hsrproxy
- arti-client
- arti-rpcserver
- arti-hyper
- tor-basic-utils
- tor-async-utils
Done using
```
for p in "${unstable[@]}"; do cargo set-version -p $p 0.19; done
```
where `unstable` contains the list above
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* crates that have no changes: none
* crates that only have non-functional changes (bump the patch version):
- test-temp-dir
- fslock-guard
- hashx
- equix
- caret
- fs-mistrust
- safelog
- retry-error
Done using
```
for c in "${non_functional[@]}"; do maint/bump_nodep $c; done
```
where `non_functional` contains the list above
|
| |\ \
| | |
| | |
| | |
| | | |
tor-circmgr: Exclude the target relay when building vanguards circuits.
See merge request tpo/core/arti!2186
|
| | | |
| | |
| | |
| | | |
This is less error-prone than the alternative.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
target.
|
| | | |
| | |
| | |
| | |
| | | |
When extending SHORT circuit stubs, the last hop shouldn't be the same
as the circuit target.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Otherwise, some of the circuits will fail (because if the target is
selected as one of the L2, L3, or M hops, it won't be able to extend the
circuit to itself).
|
| | | | |
|
| |/ / |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, the HsCircPool had a bug that caused SHORT lite-vanguards
circuits to be incorrectly extended by one hop when being repurposed as
EXTENDED circuits (EXTENDED circuits only need to be extended by extra
hop if full vanguards are in use).
Closes #1456 and #1458
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
tor-circmgr: Exclude the circ target when building paths.
Closes #1425
See merge request tpo/core/arti!2179
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
We now return an internal error if the path we've just built contains
the same hop in multiple positions.
|