| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This adds a new `AwaitIncomingStream` control message for registering an
interest in an incoming stream.
This also adds a `ClosePendingStream` control message for explicitly
closing a stream with a given END message (needed for implementing
`IncomingStream::reject`).
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This adds a new `add_ent_with_id` function for adding a new entry to the
`StreamMap`. The existing `add_ent` function auto-generates a new stream
ID, which is not good if we're a hidden service, as stream IDs are
supposed to be chosen by the OP (client). When accepting a new stream,
services, exit relays, and dir auths need to use the stream ID received
in the BEGIN cell (instead of generating a new stream ID).
|
| | |
|
| | |
|
| |
|
|
|
| |
This helps reduce code duplication, as `CtrlMsg::Shutdown` and
`CtrlMsg::AddFakeHop` are now handled in multiple places.
|
| |
|
|
|
|
| |
I think it's safe to handle `ChanMsg::Create` separately, because
there's nothing for the reactor to do until the first hop of the circuit
is created (so blocking on this _should_ be alright).
|