| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
We have decided that instead of "uniq_id" in logging, we'll use the
"<domaine>-[<type>]-id" syntax to indicate who is that unique ID.
This commit only renames circuit's unique ID to "circ_uniq_id".
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
This commit only affects logging. Whenever possible, log both the UniqId
and CircId.
This also changes the log lines which is now "uniq_id=" and "circ_id="
as the UniqId is internal and circ_id (CircId) is protocol level.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A CircId is now a circ_id and a UniqId is a unique_id so we stop
confusing them in the code.
Furthermore, channel_id that are CircId are now circ_id. Channel IDs are
different and encoded internally into a UniqId.
This is the first step to clarify semantic before we change the logging
to log both unique ID and circ ID.
No behavior change.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Typos found with codespell
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 04ab3cd848d7977baf58dd64ebfcad6aa54ecb17.
Reverted because we no longer need to "peek" into the opaque
`CircChanMsg` of a circuit reactor: now the implementation-dependent
part of the reactor is in charge of handling the channel messages,
and extracting `Relay` objects out of RELAY/RELAY_EARLY cells,
which then get processed in the base reactor.
|
| | |
|
| | |
|
| |
|
|
| |
This will tell the base `BackwardReactor` how to handle the cell.
|
| |
|
|
|
|
|
|
|
|
| |
Implements this part of the spec:
```
To tear down a circuit completely, a relay or client sends a DESTROY
cell to the adjacent nodes on that circuit, using the appropriate
direction’s circID.
```
|
| | |
|
| |
|
|
| |
This was leftover from back when this command was only for Sendmes.
|
| |
|
|
| |
This was leftover from back when the BWD was a relay-specific type.
|
| |
|
|
|
| |
This will soon be used for instructing the BWD to send other types of
messages too.
|
| |
|
|
|
|
|
| |
The backward reactor will soon need the ability to send other types of
relay messages too: it will soon need the ability to respond to EXTEND2
by sending back an EXTENDED2, so I am preemptively making this function
more general so we can reuse it.
|
| |
|
|
|
|
|
| |
In the backward reactor, we call this the `forward_reactor_rx` (because
it receives commands from the foward reactor), and in the forward
reactor we call it `backward_reactor_tx` (because it sends commands to
the backward reactor).
|
| |
|
|
|
|
|
|
|
|
| |
We settled on
* `inbound_chan{tx, rx}`, for the inbound channel (the channel towards
the guard, if we are a client, or towards the client if we are a
relay)
* `outbound_chan{tx, rx}`, for the outbound channel (the channel
towards the exit, if we are a middle relay)
|
| | |
|
| |
|
