| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
|
| |/
|
|
|
|
| |
`HopNum` will be used in `ClientCirc`'s public API when we refactor
`ClientCirc::start_conversation_last_hop` to use the provided hop rather
than always using the last one.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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 will be used by `IncomingStream` to implement `reject()`.
|
| |
|
|
|
|
|
|
|
| |
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).
|
| | |
|
| |
|
|
|
|
|
|
|
| |
When accepting a new stream, hidden services, exit relays and dirauths
don't wait for a `CONNECTED` cell from the initiator.
This commit adds constructors for building `DataStream`s and
`DataCmdChecker`s that can immediately receive data cells (and don't
expect to receive `CONNECTED` cells at all).
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These crates are at version 0.x.y, so we don't need to distinguish
new-feature changes from other changes:
```
tor-basic-utils
fs-mistrust
tor-error
tor-geoip
tor-checkable
tor-linkspec
tor-netdoc
tor-netdir
tor-persist
tor-ptmgr
tor-hsservice
```
This crate has a breaking change, but only when the semver-breaking
feature `experimental-api` is enabled:
```
tor-config
```
This crate is at version 1.x.y, but has no new public APIs, and
therefore does not need a minor version bump:
```
arti
```
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These crates had first-order breaking changes:
```
retry-error
tor-keymgr
tor-proto
tor-hsclient
tor-rtmock
```
Additionally, these broke because they re-exposed RetryError:
```
tor-circmgr
```
Additionally, these broke because they may re-expose something from
tor-proto:
```
arti-client
tor-chanmgr
tor-dirclient
tor-dirmgr
tor-guardmgr
```
Additionally, these broke for other fiddly reasons:
`tor-ptmgr` implements traits from tor-chanmgr, which has a breaking
change above.
`arti-hyper` exposes types from arti-client in its API.
|
| | |
|
| | |
|
| |
|
|
|
| |
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).
|
| |
|
|
|
|
| |
This logic from `create_firsthop()` was extracted (copied) from
`Reactor::run_once()`. A future commit will update `Reactor::run_once()`
to use `create_firsthop()`.
|
| |
|
|
|
| |
I don't know if these are needed because the rules are not documented
afaict. But it seems like probably they ought to be there?
|
| |
|
|
| |
These fns are in a feature-gated impls on feature-gated structs.
|
| |\
| |
| |
| |
| | |
clippy: Allow some of our existing code patterns
See merge request tpo/core/arti!1396
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
Overhaul send_control_message
See merge request tpo/core/arti!1367
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
The feature name is wrong now.
|
| | |
| |
| |
| | |
I think this name is fine.
|
| | | |
|
| | |
| |
| |
| | |
handle_msg is going to want this in a moment.
|
| | |
| |
| |
| |
| | |
If the circuit is just being used by us (which is likely, if we're
using this API) then the only reactor we're blocking is our own.
|
| | |
| |
| |
| |
| | |
Now, after you call start_conversation_last_hop, you can send more
messages if you like.
|
| | |
| |
| |
| |
| | |
We're going to want to do almost-the-same thing but without installing
a new handler.
|
| | |
| |
| |
| |
| | |
This is just a placeholder for now, but it'll be a thing you can send
more messages with.
|
| | |
| |
| |
| | |
Was send_control_message.
|
| | |
| |
| |
| |
| | |
We're going to let people start a conversation and either expect to
receive first, or send messages ad-hoc later.
|
| | |
| |
| |
| |
| |
| | |
Was UninstallHandler. We are going to talk more about conversations
and less about handlers (although, the fact of there being a handler
will still be visible).
|