| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
This follows the move of the client specific object.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| | |
|
| |
|
|
| |
This will be needed soon.
|
| | |
|
| | |
|
| |
|
|
|
| |
We don't really need this channel here, because we already have control
and command channels for checking if the reactor task is still alive.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
While this is technically a "reactor handle", I think RelayCirc sounds
better, because this is essentially our only public API for interacting
with a relay circuit (it will be used outside of tor-proto).
(This would also be consistent with our existing ClientCirc
client-side terminology).
|
| |
|
|
| |
This will soon become `pub`, so I am factoring it out of `reactor.rs`.
|
| |
|
|
|
|
|
| |
This implements the relay initiator side of the handshake up to the
creation of an unverified channel.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
| |
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
|