| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
We will need the ability to build one from within tor-proto.
|
| |
|
|
| |
This just removes an unnecessary `async`.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
To pull this off, ChannelProvider::get_or_launch() needed to change from
"&self" to "self: Arc<Self>" so we could pass self to the spawned task.
This is fine as the caller of ChannelProvider (circuit reactor) has a
Arc<ChanMgr>.
This also removes the PhantomData for the runtime as we now actually use
it.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
We replaced TunnelId with UniqId in the relay code a while ago.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The `TunnelId*` types will be reused in the relay reactor (exit relays
need to have the concept of a "tunnel ID" because of conflux).
Now the `relay::reactor` module only has a single import from `client`
(for the `unwrap_or_shutdown` helper, which we should be able to remove
soon). From now, we will avoid importing anything from `client` in the
`relay` module, and instead prefer refactoring the code as needed (to
pull the implementation-agnostic parts outside of `client`).
This commit has no functional changes, just code motion.
|
| |
|
|
|
|
| |
The implementation from `tunnel` is client-specific, so we are renaming
the module accordingly. The more generic parts will be pulled into a
separate module in a future commit.
|
|
|
This reorganizes the `relay_tunnel` module as per @dgoulet's
[suggestion].
[suggestion]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3162/diffs#note_3240092
|
