summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/circuit
Commit message (Collapse)AuthorAgeFilesLines
* tor-circmgr: Add a helper for displaying optional UniqIds.Gabriela Moldovan2024-02-271-1/+17
| | | | | | | | Some of the `tor_circmgr::Error` variants will include the `UniqId` of the corresponding circuit, so we'll need to be able to display it without the `Circ ` prefix. Part of #1297
* proto: Use log_ratelim to report problems delivering BEGIN messges.Nick Mathewson2024-01-171-3/+7
|
* Give an error on duplicate call to allow_stream_requests.Nick Mathewson2024-01-171-2/+2
| | | | Closes #1190
* proto: Close circuit _intentionally_ when Request Sink is dropped.Nick Mathewson2024-01-171-6/+27
| | | | | | | | | | | | | | | | | | | | | In theory, it might be better to just un-register the IncomingStreamRequestHandler when the Receiver for the stream requests is dropped. However, there are two reasons not to do so: 1. It's tricky. We never actually poll on the corresponding Sink, so there isn't a place where the Reactor would expect to get a prompt notification of closure. We only find out that the Receiver has been dropped when an attempt to send on the Sink returns an `is_disconnected` error. 2. It's unnecessary. In the Tor protocols, once we have decided to accept incoming stream requests on a circuit, we want to continue to do so until one of the parties closes the circuit. I've documented this in several comments, in case whe want to get fancier in the future. Closes #1188.
* proto: Send END when buffer of IncomingRequests is fullNick Mathewson2024-01-171-11/+14
| | | | Closes #1189.
* Convert a TODO HSS about excessive BEGINs to #1189.Nick Mathewson2024-01-101-1/+1
|
* proto: Downgrade TODO HSS about HopNum in IncomingStreamRequestCommentNick Mathewson2024-01-101-5/+4
| | | | | | | These comments are about internal representations and future extensions. Also, add a fail-safe check to make sure that hop_num consistency is enforced.
* proto: Downgrade TODO HSS comments about hop lookupNick Mathewson2024-01-101-2/+2
|
* proto: Change some TODO HSS comments to refer to #1188Nick Mathewson2024-01-101-3/+3
|
* clippy nightly: For now, locally allow blocks_in_conditionsIan Jackson2024-01-021-0/+1
| | | | | | Filed https://gitlab.torproject.org/tpo/core/arti/-/issues/1176 proposing a final fix.
* clippy: Replace many calls to .get(0) with .first()Ian Jackson2024-01-021-1/+1
| | | | | FTR I don't think agree with clippy on this question, but then I often don't.
* Rename {Any}RelayCell to {Any}RelayMsgOuterNick Mathewson2023-12-144-21/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* debug log: Downgrade circuit lifecycle messages to traceIan Jackson2023-11-291-4/+4
| | | | | | This makes it possible to see the wood for the trees. This may be controversial, but I think it's an improvement.
* Downgrade some messages to traceIan Jackson2023-11-291-1/+1
| | | | | These messages are very verbose and I doubt anyone will want them, usually, even when debugging.
* Fix 'target' in doc comment for create_firsthop_ntorJim Newsome2023-11-271-1/+1
|
* Add `ClientCirc::extend_ntor_v3`Jim Newsome2023-11-271-0/+40
|
* tor-proto::circuit::reactor: handle server auxiliary handshake dataJim Newsome2023-11-271-10/+81
|
* Add Reactor::create_firsthop_ntor_v3Jim Newsome2023-11-271-0/+50
|
* Use HandshakeType in Extend2 and CircuitExtender::beginJim Newsome2023-11-271-2/+2
|
* tor-proto: make ClientHandShake and ServerHandshake generic over aux dataJim Newsome2023-11-151-22/+17
|
* ClientHandshake: extend to support ntorv3 extensionsJim Newsome2023-11-151-4/+16
|
* CircuitHandshake::Ntor::ed_identity clarify doc-commentJim Newsome2023-11-151-2/+2
| | | | | Use consistent phrasing when describing the two key fields to make it clear they're referring to the same relay.
* circuit: On SendMsgAndInstallHandler, tolerate None handlerNick Mathewson2023-11-021-0/+1
| | | | | | | | | | | | 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.
* circuit::reactor: Remember that meta_handler is Send.Nick Mathewson2023-11-021-2/+2
| | | | | | (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.)
* 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.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 02:05:39 +0000