summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/circuit
Commit message (Collapse)AuthorAgeFilesLines
* Add a caret_int HandshakeType for HTYPE constantsJim Newsome2023-10-261-2/+2
|
* Change `CircId` to never be zeroJim Newsome2023-10-251-1/+1
| | | | | | | | | | 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.
* Convert StreamId to NonZeroU16Jim Newsome2023-10-255-43/+50
|
* proto: Revise the behavior of IncomingStream::discard().Nick Mathewson2023-10-191-8/+30
| | | | | | | | | | | | | 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.
* proto: Remove TODOs about panics on double-close.Nick Mathewson2023-10-191-14/+0
| | | | | | | 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.
* proto: Have EndSent remember if we have dropped the stream target.Nick Mathewson2023-10-192-14/+46
| | | | | The rule is that we allow up to one explicit `close_pending`, followed by exactly one final `mpsc::Sender` drop.
* proto: Give StreamMap::terminate a "why" argumentNick Mathewson2023-10-192-7/+45
| | | | | We will use this to enforce correct ordering on "close" vs "drop" APIs.
* Add comments about another problem with close_pending().Nick Mathewson2023-10-171-0/+14
| | | | See #1065 for more information here.
* proto: Remove a TODO about merging two functions.Nick Mathewson2023-10-121-2/+0
| | | | | There is some similarity, but there's not really a logical way to combine the two that actually results in less, clearer code.
* Lower and downgrade a TODO about StreamID and NonZeroU16.Nick Mathewson2023-10-121-1/+0
|
* oneshot: Apply deferred rustfmt churnIan Jackson2023-10-111-1/+1
| | | | cargo fmt, precisely.
* oneshot: Use veneer in tor-protoIan Jackson2023-10-111-1/+2
|
* tor-proto: Use HopNum::display() instead of Debug representation.Gabriela Moldovan2023-08-251-3/+3
|
* tor-proto: Remove the Display impl of HopNum (fmt).Gabriela Moldovan2023-08-251-6/+6
|
* tor-proto: Remove the Display impl of HopNum.Gabriela Moldovan2023-08-251-9/+9
| | | | | This removes the `Display` impl of `HopNum` and replaces its usage with `HopNum::display`.
* Run maint/add_warning to add lint block everywhereIan Jackson2023-08-234-0/+4
|
* proto: new ClientCirc::send_raw_msg function.Nick Mathewson2023-08-211-0/+22
| | | | Closes #1010.
* tor-proto: Make ClientCirc::allow_stream_requests take a HopNum.Gabriela Moldovan2023-08-181-3/+15
| | | | | | | | | | 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
* Apply some churn from rustfmt (beta)Ian Jackson2023-08-161-1/+1
|
* proto: Fix a type-complexity warning.Nick Mathewson2023-08-141-7/+17
|
* proto: API to expose the `CircuitBinding` type.Nick Mathewson2023-08-141-2/+3
| | | | Closes #993
* proto: Take CircuitBinding one step forward into Reactor::add_hop.Nick Mathewson2023-08-142-7/+23
|
* proto: Add (not-yet-exposed) code to remember and use KH valuesNick Mathewson2023-08-142-3/+3
| | | | | | | | 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.
* Merge branch 'proto-flaky-test' into 'main'gabi-2502023-08-041-2/+10
|\ | | | | | | | | | | | | tor-proto: allow_stream_requests now waits until the control message is received. Closes #994 See merge request tpo/core/arti!1474
| * tor-proto: Shut down the reactor if an error occurs in incoming stream ↵Gabriela Moldovan2023-08-041-4/+4
| | | | | | | | | | | | | | | | 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).
| * tor-proto: reject() now waits until the control message is received.Gabriela Moldovan2023-08-041-1/+5
| | | | | | | | | | | | | | | | 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.
| * tor-proto: allow_stream_requests now waits until the control message is ↵Gabriela Moldovan2023-08-041-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | proto: methods to wait until a channel/circuit is shut down.Nick Mathewson2023-08-041-1/+12
|/ | | | | | | | | | | | | | | | | | 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.
* tor-proto: Add ClientCirc::start_conversation().Gabriela Moldovan2023-08-042-3/+3
| | | | | | | | | | | 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
* tor-proto: Handle new BEGIN cells for rejected stream.Gabriela Moldovan2023-08-031-0/+13
| | | | | | | | | 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.
* tor-proto: Add note about making hop_num optional.Gabriela Moldovan2023-08-031-0/+7
|
* tor-proto: Add a TODO about checking if a hop is allowed to create streams.Gabriela Moldovan2023-08-031-0/+3
|
* tor-proto: Remove unnecessary else-branch.Gabriela Moldovan2023-08-031-38/+38
| | | | | We return early if `message_closes_stream == true`, so we can get rid of the `else` to remove one level of indentation.
* tor-proto: Update the stream map if we get an END message.Gabriela Moldovan2023-08-031-1/+5
| | | | | This handles the previously not handled `message_closes_stream == true` case.
* tor-proto: Handle RELAY_BEGIN cells if we have an incoming req handler.Gabriela Moldovan2023-08-031-0/+84
|
* tor-proto: Add reactor control commands for accepting/closing incoming streams.Gabriela Moldovan2023-08-031-4/+62
| | | | | | | | | 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`).
* tor-proto: Add types for sharing stream request info with the reactor.Gabriela Moldovan2023-08-031-0/+49
|
* tor-proto: Add a helper for adding a stream entry with a specific stream ID.Gabriela Moldovan2023-08-031-0/+35
| | | | | | | | | 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).
* tor-proto: Rename create_firsthop() to wait_for_create().Gabriela Moldovan2023-07-271-2/+2
|
* tor-proto: Update handle_control docs.Gabriela Moldovan2023-07-261-1/+1
|
* tor-proto: Add functions for handling Shutdown and AddFakeHop messages.Gabriela Moldovan2023-07-261-42/+37
| | | | | This helps reduce code duplication, as `CtrlMsg::Shutdown` and `CtrlMsg::AddFakeHop` are now handled in multiple places.
* tor-proto: Extract first-hop creation to a separate function.Gabriela Moldovan2023-07-261-37/+11
| | | | | | 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).
* tor-proto: Create a function for handling the initial CREATE cell.Gabriela Moldovan2023-07-261-1/+89
| | | | | | This logic from `create_firsthop()` was extracted (copied) from `Reactor::run_once()`. A future commit will update `Reactor::run_once()` to use `create_firsthop()`.
* tor-circmgr: Add two possibly-needed docsrs annotationsIan Jackson2023-07-121-0/+1
| | | | | 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?
* tor-proto: Conversation: drop two otiose cfg(feature)Ian Jackson2023-07-121-1/+0
| | | | These fns are in a feature-gated impls on feature-gated structs.
* Merge branch 'clippy-allow' into 'main'Ian Jackson2023-07-114-0/+4
|\ | | | | | | | | clippy: Allow some of our existing code patterns See merge request tpo/core/arti!1396
| * Run maint/add_warning to actually apply new lint allowsIan Jackson2023-07-104-0/+4
| |
* | Merge branch 'conversation' into 'main'Alexander Færøy2023-07-102-24/+90
|\ \ | |/ |/| | | | | Overhaul send_control_message See merge request tpo/core/arti!1367
| * tor-proto: run rustfmtIan Jackson2023-06-302-7/+14
| |
| * tor-proto conversations: Drop a TODOIan Jackson2023-06-301-1/+0
| | | | | | | | I think this name is fine.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 10:10:47 +0000