| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
This simplifies the calling code, which will, in turn, make it easier
for us to simplify the logic in ConfluxSet::next_circ_action() and
abolish the questionable use of FuturesUnordered.
|
| |
|
|
|
|
| |
This enables us to make the conflux handler logic
implementation-agnostic (we want to avoid using `CircuitCmd` here,
because it is specific to client circuits).
|
| |
|
|
|
|
|
|
|
|
| |
This moves the shared types under `tor_proto::conflux`.
Note: the shared types currently import `CircuitCmd` from `client`. A
future commit will change the signature of `handle_msg` to return
something other than `CircuitCmd` (this will also improve readability,
because in reality, that function can never return most `CircuitCmd`
variants).
|
| |
|
|
|
|
|
| |
`tor_proto::conflux` is where the shared conflux logic will live.
Soon the generic parts of the conflux handlers will be moved there
(whereas the client-specific `AbstractConfluxMsgHandler` impl will
continue living under `tor_proto::client`).
|
| |
|
|
|
|
| |
This will enable us to pull `ConfluxMsgHandler` outside of the `client`
module (this is needed because relays are meant to use this type as
well, but with a different `AbstractMsgHandler`)
|
| |
|
|
| |
Also removes all the TODOs related to #2031 (which is now addressed).
|
| |
|
|
| |
Closes #2031
|
| |
|
|
| |
This partially addresses #2031
|
| |
|
|
|
|
| |
This will be needed for the SWITCH seqno validation logic.
Part of #2031
|
| |
|
|
|
|
| |
These will be used for validating SWITCH cells.
Part of #2031
|
| | |
|
|
|
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.
|