| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| | |
This is in keeping with the behavior of C tor, and of
torspec!179.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
While looking for differences, we found that C tor always
omits the flags and the hostname from a BEGIN message sent on an
onion service circuit. In torspec!179, we specified that behavior.
This patch brings arti into conformance.
Closes #1077.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
|
|
| |
See #1065 for more information here.
|
| |
|
|
|
|
|
|
|
| |
It turns out that we can make `IncomingStream::reject()` consume
self, thus making it impossible to hit the double-close error
from outside the `tor-proto` crate.
Also, we rename `StreamTarget::close()` to `close_pending()` to
better reflect its limited applicability.
|
| | |
|
| |
|
|
|
|
|
| |
The function never yields anything but an `Ok`, so we can
simplify its type.
(Not a stable feature, so no semver entry needed)
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
proto: new ClientCirc::send_raw_msg function.
Closes #1010
See merge request tpo/core/arti!1525
|
| | | |
|
| | |
| |
| |
| | |
Closes #1010.
|
| |/
|
|
|
| |
Nightly rustdoc now warns if you have a link that isn't necessary,
and if you have a link that might refer to two different things.
|
| |
|
|
|
|
|
| |
This adds a test that checks if the reactor is shut down if it receives
an incoming stream request from an unexpected hop.
Part of #1009
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |\
| |
| |
| |
| | |
tor-proto: remove unused import
See merge request tpo/core/arti!1493
|
| | |
| |
| |
| |
| | |
This commit removes an unused import within the test module of the
`tor_proto::circuit` module.
|
| | | |
|
| | |
| |
| |
| | |
Closes #993
|
| |/ |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
blocking.
Instead of having 2 version of `StreamTarget::close` (a blocking one and
a nonblocking one), we can just return the `oneshot::Receiver` for
receiving the reactor's response and let the caller of
`StreamTarget::close` decide whether to block.
This allows us to reduce some code duplication in the `IncomingStream`
implementation.
|
| |
|
|
|
|
|
| |
reactor to respond.
This will be used for implementing `Drop` for `IncomingStream` (it
needs to "reject" the stream on drop).
|
| |\
| |
| |
| |
| |
| |
| | |
tor-proto: allow_stream_requests now waits until the control message is received.
Closes #994
See merge request tpo/core/arti!1474
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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 `sleep` is to give the reactor task a chance to process the
`AwaitIncomingStream` message. With an 100ms, this test sometimes fails
because for some reason the reactor doesn't get a chance to process the
`AwaitIncomingStream` control command before the BEGIN cell from the
client task is received. This bumps the sleep time to 200ms for now
(TODO: follow-up with an MR with a less flaky approach).
While trying to repro the issue, I found another corner case for which
I've added a TODO HSS.
|
| |
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
