| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Filed
https://gitlab.torproject.org/tpo/core/arti/-/issues/1176
proposing a final fix.
|
| |
|
|
|
| |
FTR I don't think agree with clippy on this question, but then I often
don't.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit is pure renaming, done automatically with rust-analyzer.
Comment fixes and other cleanups will be in the subsequent commits.
We're doing this renaming because we need a name for
the combination of a `RelayMsg` and an `Option<StreamId>`
that we use when we have a `RelayMsg`
we intend to route to a given stream or circuit internally.
Previously we called this a `RelayCell`,
but that name was already somewhat inaccurate,
and will become _very_ inaccurate with the arrival of prop340,
which breaksthe 1:1 relationship between relay cells
and relay messages.
(If we didn't do this renaming now, we'd soon be making
the relationship between `UnparsedRelayCell`and `RelayCell`
many-to-many, which would be ridiculous and confusing.)
The `RelayMsgOuter` name is a placeholder:
We expect that we'll want to rename this type,
and may also want to rename `RelayMsg`,
and unify our vocabulary in other areas too.
But such a renaming will have to wait
for a larger discussion affecting the specifications,
so that we can use the same vocabulary everywhere.
|
| |
|
|
|
|
| |
This makes it possible to see the wood for the trees.
This may be controversial, but I think it's an improvement.
|
| |
|
|
|
| |
These messages are very verbose and I doubt anyone will want them,
usually, even when debugging.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Use consistent phrasing when describing the two key fields to make it
clear they're referring to the same relay.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Previously it was possible for `handler` to be None only when
`msg` was also None, which would make SendMsgAndInstallHandler into
a no-op. Now, if `msg` is present but `handler` is absent, we
use the previously installed handler, which I think was our
intention.
Without this patch, `Conversation::send_message` simply won't work.
Fixes #1085.
|
| |
|
|
|
|
| |
(We already require that it is Send when the client gives it to us
in circuit.rs, but we had previously forgotten that when we stored
it in the Reactor.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
This changes the internal representation to be `NonZeroU32` instead of
just `u32`.
Various places where a circuit ID is optional now use `Option<CircId>`.
Fixes a bug in `CircIdRange::sample` that would previously return a
circuit ID of 0, when the rng returned 0x8000_0000 for a low range.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Because dropping a `StreamTarget` causes the circuit reactor to send
an End, the previous do-nothing implementation of `discard()` wasn't
sufficient to cause the request to be ignored without sending an
End.
This commit modifies our "close pending stream" behavior to only
optionally send an End message. To avoid confusion, I'm using a new
`CloseStreamBehavior` enum rather than an `Option<End>`, since we
had previously used `None` in some cases to indicate a default
(misc) end message.
|
| |
|
|
|
|
|
| |
Now that `StreamMap::terminate` no longer panics, and now that it
permits the kind of double-call that we allow, we can close #1065.
Closes #1065.
|
| |
|
|
|
| |
The rule is that we allow up to one explicit `close_pending`,
followed by exactly one final `mpsc::Sender` drop.
|
| |
|
|
|
| |
We will use this to enforce correct ordering on "close" vs "drop"
APIs.
|
| |
|
|
| |
See #1065 for more information here.
|
| |
|
|
|
| |
There is some similarity, but there's not really a logical way
to combine the two that actually results in less, clearer code.
|
| | |
|
| |
|
|
| |
cargo fmt, precisely.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This removes the `Display` impl of `HopNum` and replaces its usage with
`HopNum::display`.
|
| | |
|
| |
|
|
| |
Closes #1010.
|
| |
|
|
|
|
|
|
|
|
| |
For consistency with the other `ClientCirc` APIs,
`ClientCirc::allow_stream_requests` now takes a `HopNum` argument. Upon
receiving an incoming stream request, the reactor now checks if the
request came from the hop specified in `allow_stream_requests` (and if
it came from a different hop, the circuit is closed).
Part of #1009
|
| | |
|
| | |
|
| |
|
|
| |
Closes #993
|
| | |
|
| |
|
|
|
|
|
|
| |
These values are computed as part of the circuit extension
handshake, and are used as MAC keys to bind `ESTABLISH_INTRO`
messages to a particular circuit so that they can't be replayed.
Part of #993.
|
| |\
| |
| |
| |
| |
| |
| | |
tor-proto: allow_stream_requests now waits until the control message is received.
Closes #994
See merge request tpo/core/arti!1474
|
| | |
| |
| |
| |
| |
| |
| |
| | |
init/close.
Propagating the error means will cause the reactor to shut down (there's
not much the control message sender can do about it, so there's no point
in sending it the error).
|
| | |
| |
| |
| |
| |
| |
| |
| | |
As a result, by the time the `reject` future resolves, the stream has
been removed from the reactor's stream map and the corresponding END
cell has been sent.
Fixes #998.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
received.
`ClientCirc::allow_stream_requests` is now `async` and waits until the
`AwaitIncomingStream` control message is processed by the reactor.
This guarantees that by the time the `allow_stream_requests` future
resolves, the reactor is ready to process BEGIN/BEGIN_DIR/RESOLVE cells.
Previously, the client tasks from allow_stream_requests tests had to
sleep before sending the BEGIN cell to give the reactor time to process
the `AwaitIncomingStream` control message (which tells the reactor to
expect incoming BEGIN/BEGIN_DIR/RESOLVE cells on the circuit).
Fixes #994
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The implementation here is perhaps excessively simple: we put
a `oneshot::Sender` in the `Reactor` object, and a
`Shared<oneshot::Receiver>` in the circuit or channel. When
the reactor is dropped, any copy of the `Shared<Receiver>` will
yield `Err(Cancelled)`.
I'm marking these methods as experimental because I'm not sure I've
thought of all the implications here, and we might want to change
things around.
Down the road, these methods might want to yield a `Result<>`
indicating why the reactor was shut down.
This feature was inspired by a request from Saksham Mittal, and a
felt need while working on !1472.
|
| |
|
|
|
|
|
|
|
|
|
| |
This will enable hidden services to send `RENDEZVOUS1` messages to the
`N`th hop of the circuit rather than the `N + 1`th virtual one (which
can only used after the client and service have completed the
introduction handshake).
This also deprecates `start_conversation_last_hop`.
Closes #959
|
| |
|
|
|
|
|
|
|
| |
This updates the reactor to call the incoming stream handler even for
streams for which we have a stream map entry of `EndSent`. If we've
sent an END message for a stream but have not yet received an END
message back from the other party, but we later receive a BEGIN from
them, it is safe to assume we cam remove the stream from the stream map
and handle the new incoming stream request.
|
| | |
|
| | |
|
| |
|
|
|
| |
We return early if `message_closes_stream == true`, so we can get rid of
the `else` to remove one level of indentation.
|
| |
|
|
|
| |
This handles the previously not handled `message_closes_stream == true`
case.
|
| | |
|
