summaryrefslogtreecommitdiff
path: root/crates
Commit message (Collapse)AuthorAgeFilesLines
...
* | proto: Add a ConfluxSet::remove_unchecked method.Gabriela Moldovan2025-07-251-0/+16
| | | | | | | | | | This method will enable us to remove some duplicated code, as well as the `element_idx` function.
* | tor-hsservice: Fix doccomment link.Wesley Aptekar-Cassels2025-07-231-1/+1
| |
* | tor-hsservice: Add monotonic request id to RendRequestOrdByEffort.Wesley Aptekar-Cassels2025-07-231-4/+23
| | | | | | | | | | This ensures that even in situations where multiple requests are received at the exact same time, we will not drop any requests.
* | tor-hsservice: Add note about SUGGESTED_EFFORT_DEADZONE.Wesley Aptekar-Cassels2025-07-231-0/+4
| |
* | tor-hsservice: Fix typo.Wesley Aptekar-Cassels2025-07-231-4/+4
| |
* | tor-hsservice: Remove remaining `as` casts from suggested effort update.Wesley Aptekar-Cassels2025-07-231-12/+23
| | | | | | | | | | This basically converts everything to use the num_traits conversion function, and explicitly panics on errors.
* | tor-hsservice: Remove another use of `as`.Wesley Aptekar-Cassels2025-07-232-3/+8
| | | | | | | | | | | | This pulls in num_traits (which is already a dependency for PoW) to allow f64 casts that for reasons I do not understand are not implemented via TryFrom in the standard library.
* | tor-hsservice: Convert as into checked conversion.Wesley Aptekar-Cassels2025-07-231-1/+1
| | | | | | | | | | This should never happen, as the queue size is limited to well below u32. However, it's still nicer not to use `as`.
* | tor-hsservice: Make num_dequeued u32 instead of usize.Wesley Aptekar-Cassels2025-07-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | We need to divide a Duration by this, and Duration only supports division by u32. This is, in a sense, just pushing around where the overflow would happen, (from the conversion in the suggested update to the increment when a item is dequeued). However, this overflow is so unlikely to happen (it would require more that 14 million requests per second) that it does not seem worth slowing down the increment operation to try to handle it.
* | tor-hsservice: Fix typos.Wesley Aptekar-Cassels2025-07-231-6/+6
| |
* | tor-hsservice: Use Mutex for suggested_effort.Wesley Aptekar-Cassels2025-07-231-16/+16
| | | | | | | | | | | | | | | | This has fewer weird edge cases than RwLock does. It might also be reasonable to make this a AtomicU32 (or AtomicEffort which wraps AtomicU32), but that's slightly more complex, so I've opted for a mutex for now.
* | tor-hsservice: Add tests for PowManager control loop.Wesley Aptekar-Cassels2025-07-231-21/+244
| | | | | | | | | | | | This modifies the code to be more testable (making it generic over RendRequest, getting the time from the runtime rather than Instant::now(), etc) and adds some tests for the PoW control loop.
* | tor-hsservice: Make PowManager generic over RendRequests.Wesley Aptekar-Cassels2025-07-231-12/+15
| |
* | tor-hsservice: Initial work towards mocking RendRequest.Wesley Aptekar-Cassels2025-07-231-24/+39
| |
* | tor-hsservice: Allow mocking PowManager.Wesley Aptekar-Cassels2025-07-231-4/+16
| |
* | tor-hsservice: Enforce maximum RendRequest queue size.Wesley Aptekar-Cassels2025-07-231-0/+12
| |
* | tor-hsservice: Update suggested effort in PowManager main loop.Wesley Aptekar-Cassels2025-07-231-1/+51
| |
* | tor-hsservice: Add suggested effort update function.Wesley Aptekar-Cassels2025-07-231-0/+63
| |
* | tor-hsservice: Give PowManager reference to RendRequestReceiver.Wesley Aptekar-Cassels2025-07-231-3/+8
| |
* | tor-hsservice: Allow constructing RendRequestReceiver without spawning.Wesley Aptekar-Cassels2025-07-231-19/+21
| | | | | | | | | | | | This will allow the PowManager to have a copy of RendRequestReceiver, which is important to allow the PowManager update loop to control the suggseted_effort updating.
* | tor-hsservice: Add state for prop362 update loop.Wesley Aptekar-Cassels2025-07-231-1/+45
| |
* | tor-hsservice: Change storage of PoW suggested_effort.Wesley Aptekar-Cassels2025-07-231-4/+21
| | | | | | | | | | | | | | This makes the suggested_effort value a Arc<RwLock<Effort>>, which is shared between the PowManager (as a reader) and the RendRequestReceiver (as a writer), since the RendRequestReceiver has the information needed to update the suggested_effort value.
* | tor-hsservice: Implement PoW queue with BTreeSet.Wesley Aptekar-Cassels2025-07-231-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | The updated PoW control loop in prop362 requires this data structure to be double ended, which BinaryHeap is not. I benchmarked [email protected] against BTreeSet on a synthetic benchmark based on what I expected typical load to look like, and found that BTreeSet performed much better. It is additionally in the standard library, and is maintained, which no third-party double ended priority queue crate seems to be. Given that, BTreeSet seems like a reasonable thing to build on, although we should provide metrics on the performance of this queue so operators can let us know if it seems to be a problem in real-world use.
* | tor-hsservice: RendRequestOrdByEffort use time as tiebreaker.Wesley Aptekar-Cassels2025-07-231-5/+15
| | | | | | | | | | | | | | Since this will be used in a BTreeSet, we need to ensure that in practice no two requests will be equal. Ordering by a combination of effort and time received should be sufficient for this, and gives us the behaviour we want.
* | Merge branch 'cgo-integration' into 'main'Nick Mathewson2025-07-2310-82/+222
|\ \ | | | | | | | | | | | | | | | | | | Negotiate and use CGO. Closes #1947 and #1945 See merge request tpo/core/arti!3069
| * | tor-proto: Temporary measure to disable CGO.Nick Mathewson2025-07-231-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit prevents us from ever deciding that another relay supports CGO, which prevents us from trying to negotiate it. It also adds an assertion to make sure that we haven't tried to negotiate it. We can remove this once we're ready to have CGO turned on: right now it's blocked on being able to negotiate CC. I'm adding this so we can merge this branch (so that I can stop rebasing it.)
| * | Downgrade an XXXX to a TODO.Nick Mathewson2025-07-231-1/+3
| | |
| * | Remove now-needless allow(unused).Nick Mathewson2025-07-231-1/+0
| | |
| * | Refactor/simplify HopSettings constructionNick Mathewson2025-07-232-60/+108
| | | | | | | | | | | | | | | | | | | | | We now take an enum describing whether we are doing no negotiation, HsV3 negotiation, or full negotiation. This lets us do away with the notions of default relay crypto, and of declaring post-facto that no negotiation has occurred.
| * | Rename and invert the sense of requires_stream_level_sendmes.Nick Mathewson2025-07-232-5/+9
| | | | | | | | | | | | | | | Instead call it compatible_with_cgo, which is what we actually care about in this context.
| * | proto: Send extensions as appropriate to negotiate CGO.Nick Mathewson2025-07-233-1/+54
| | | | | | | | | | | | Let's see if it works!
| * | proto: Construct CGO instances if that is what is selected.Nick Mathewson2025-07-232-2/+15
| | |
| * | proto: Take format+crypto settings from HopSettingsNick Mathewson2025-07-237-54/+58
| | | | | | | | | | | | | | | Since these will be negotiated (or determined as part of negotiation) they belong in HopSettings.
| * | protover: Allocate a capability number for RELAY_CRYPT_CGO.Nick Mathewson2025-07-231-0/+7
| | |
* | | tor-llcrypto: fix typotcyrus2025-07-231-1/+1
| | | | | | | | | | | | | | | `tor_llcrypto::pk::ed25519::PublicKey` is based on `ed25519_dalek::VerifyingKey` and not `ed25519_dalek::SigningKey`.
* | | tor-hscrypto: fix typostcyrus2025-07-232-3/+3
|/ /
* | tor-keymgr: Add err::Error::KeystoreNotFoundhjrgrn2025-07-232-2/+9
| |
* | tor-basic-utils: add `assert_val_impl_trait!` macroSteven Engler2025-07-172-2/+24
| |
* | tor-proto: replace `DataReader`Steven Engler2025-07-172-44/+48
| | | | | | | | | | | | | | | | | | | | | | | | `DataReader` -> `DataReaderInner` `DataReaderNew` -> `DataReader` This means that the `DataReader` now supports XON/XOFF flow control using the `XonXoffReader`. This means that it can receive requests for a new drain rate from the reactor, and can send the new drain rate to the reactor once there is no more stream data queued.
* | tor-proto: add `DataReaderNew`Steven Engler2025-07-173-5/+75
| | | | | | | | This will later become `DataReader`.
* | tor-proto: add `StreamReceiver::is_empty()`Steven Engler2025-07-171-1/+39
| |
* | tor-proto: add the `XonXoffReader` and connect it to the reactorSteven Engler2025-07-1711-15/+267
| | | | | | | | | | | | | | | | | | | | | | | | The idea here is that the reactor builds an `XonXoffReaderCtrl` for the new stream, and the `XonXoffReaderCtrl` can receive notifications from the reactor's `StreamFlowControl`. The `XonXoffReaderCtrl` can be combined with any `AsyncRead` to build a `XonXoffReader`, essentially wrapping the `AsyncRead` with a type that handles XON/XOFF flow control. Essentially, the reactor gives you a type that allows you to add XON/XOFF flow control support to any `AsyncRead`. We will add this `XonXoffReader` to the `DataReader` in a future commit.
* | tor-proto: add plumbing for sending XONSteven Engler2025-07-176-5/+171
| | | | | | | | | | Nothing actually causes an XON to be sent yet. But this adds the code so that anything holding the `StreamTarget` can request to send an XON.
* | tor-proto: move some code into a `approx_stream_bytes_buffered()` fnSteven Engler2025-07-171-6/+11
| |
* | Merge branch 'flow-ctrl' into 'main'opara2025-07-1624-188/+663
|\ \ | | | | | | | | | | | | tor-proto,tor-cell: Code refactoring and add support for sending XOFF messages See merge request tpo/core/arti!3094
| * | tor-cell: add `FlowCtrlVersion::V0`Steven Engler2025-07-162-12/+5
| | |
| * | tor-proto: send XOFF messages when the queue grows too largeSteven Engler2025-07-166-6/+121
| | |
| * | tor-proto: add `CongestionControl::uses_xon_xoff()`Steven Engler2025-07-163-0/+19
| | |
| * | tor-proto: add dedicated types for the incoming stream queueSteven Engler2025-07-1610-24/+275
| | | | | | | | | | | | | | | XON/XOFF flow control will want to know how many data bytes are queued on a stream, so the new types track that.
| * | tor-cell: change `UnparsedRelayMsg::data_len`Steven Engler2025-07-153-9/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | It now performs some validation and can return a `Result`. We perform validation here since different cell formats may have different maximum data lengths in the future, and `UnparsedRelayMsg` doesn't expose the cell format so it's difficult to perform this validation at a higher layer.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 23:08:04 +0000