summaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/channel.rs
Commit message (Collapse)AuthorAgeFilesLines
* chanmgr: Use CircIdRange::Low for relay channelsDavid Goulet2026-02-251-1/+5
| | | | | | Closes #1601 Signed-off-by: David Goulet <[email protected]>
* proto: Remove Default of PeerInfo/Addr and use const insteadDavid Goulet2026-02-191-2/+2
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Fix clippy errorsDavid Goulet2026-02-191-3/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Put a PeerInfo in ChannelDavid Goulet2026-02-191-1/+9
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Use the PeerAddr accross channel handshakeDavid Goulet2026-02-191-2/+10
| | | | | | | This is a large change but it is basically using PeerAddr in the channel builder through the channel handshake code and into the Channel itself. Signed-off-by: David Goulet <[email protected]>
* proto: Remove unused ChannelBuilderDavid Goulet2026-02-191-77/+3
| | | | Signed-off-by: David Goulet <[email protected]>
* chan: Use Canonicity when choosing a channelDavid Goulet2026-02-121-3/+10
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Channel finish() now handles canonicityDavid Goulet2026-02-121-3/+7
| | | | | | | | | | | | | | All handshake pass the NETINFO cell, the advertised addresses (if any) and the peer address in order to build the Canonicity and build the channel with it. In order to pull this off, the "my_addrs" were added to several object along the NETINFO cell. We also pass the channel method when connecting (initiator) to a relay as we need this for this canonicity build. Signed-off-by: David Goulet <[email protected]>
* proto: Implement a Canonicity structDavid Goulet2026-02-121-1/+51
| | | | | | | | | | | | | | | | | This struct will be put in a Channel and derived from the received NETINFO cell. This follows the C-tor implementation for which we have two indicator of canonicity: 1. Peer is canonical: the address they advertise in the NETINFO cell matches the one we see on the TCP connection. 2. Canonical to peer: the peer sees us as canonical. Those flag will get used to select "the best" channel. Signed-off-by: David Goulet <[email protected]>
* proto: Add Channel function for launching outbound relay circuitsGabriela Moldovan2026-02-051-0/+47
| | | | This is currently very similar to its client counterpart.
* proto: Remove unused traits after type refactoringDavid Goulet2026-02-041-73/+0
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Move TimeoutEstimator to utilGabriela Moldovan2026-01-291-1/+2
| | | | | This will be used in the stream reactor too (and the stream reactor will eventually replace the corresponding client impl).
* proto: Improve some comments in relay moduleDavid Goulet2026-01-221-1/+2
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Remove async for VerifiableChannel::check()David Goulet2026-01-221-2/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Move cell sending out of check() and into finish()David Goulet2026-01-221-5/+0
| | | | | | | | | | | | | This is so check() only authenticate a channel. The finish() function now only sends back the missing cells and build the final Channel. To pull this off, the AUTHENTICATE cell and our IP addresses need to be copied into the VerifiedRelayChannel. This allows us to remove complexity into the check() function as well and future commit will remove the async. Signed-off-by: David Goulet <[email protected]>
* proto: Authenticate a relay channelDavid Goulet2026-01-221-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit is a bit loaded but it is coherent. First, we set Eq and PartialEq to the channel message Authenticate so we can compare it with the one we expected. Second, the AuthenticationCell enum is introduced to store either an AUTH_CHALLENGE or an AUTHENTICATE since one side of the handshake can only have one. This allows us to store one or the other in UnverifiedRelayChannel. Depending on what we have, the authentication process is different as it dictates which side we are on (initiator vs responder). Keep in mind that the handshake code enforces receiving a AUTH_CHALLENGE along side CERTS. And same goes for AUTHENTICATE which means that if we have an AUTH_CHALLENGE in the UnverifiedRelayChannel, it is certain that the other side wants to authenticate and we are the initiator. Finally, the sending of CERTS and AUTHENTICATE by the initiator is now in UnverifiedRelayChannel::check() done right after verifying the channel CERTS and holding a "VerifiedChannel" object. This means that the last piece, sending the `NETINFO` by the initiator will be done in the check() but in a future commit. This leaves the VerifiableChannel::finish() to send nothing and only finalize the channel with the NETINFO (canonicity). Signed-off-by: David Goulet <[email protected]>
* proto: Make VerifiableChannel::check() asyncDavid Goulet2026-01-221-1/+2
| | | | | | | | | Relay initiator needs to send CERTS and AUTHENTICATE in that function after verifiying the channel. And thus require to be async. Signed-off-by: David Goulet <[email protected]>
* proto: Make CERTS cell optionnable for UnverifiedChannelDavid Goulet2026-01-221-0/+7
| | | | | | | | | | | | | | | This requires to make a series of cert and digest also optionnable in the VerifiedChannel. This change is needed because as a relay responder, you might get the CERTS or not depending on if the other side wants to authenticate. Client and bridges do not authenticate and thus it is expected to not have a CERTS cell. This leads to the UnverifiedChannel::check() function to return early with a VerifiedChannel without any identity attached to it. Signed-off-by: David Goulet <[email protected]>
* proto: Fix comments documentationDavid Goulet2026-01-131-1/+1
|
* proto: Seal the VerifiableChannel and FinalizableChannel traitsDavid Goulet2026-01-131-2/+10
| | | | | | They are public but avoid anyone outside implementing them. Signed-off-by: David Goulet <[email protected]>
* proto: Improve channel trait commentsDavid Goulet2026-01-131-0/+7
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Add link_protocol() to VerifiableChannel traitDavid Goulet2026-01-131-0/+4
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Add traits for public channel viewsDavid Goulet2026-01-131-0/+53
| | | | | | | | | | | | | | Add traits that will be returned outside tor-proto allowing us to not expose client and relay specific channels. The goal is for the tor-chanmgr to get those objects implementing those traits and can build and run the reactor without knowing the specific underlying type. This allows us to have less code duplication and less client/relay distinction in the chanmgr. Signed-off-by: David Goulet <[email protected]>
* proto: Remove unused restricted channel msg setDavid Goulet2025-12-101-26/+0
| | | | Signed-off-by: David Goulet <[email protected]>
* opentelemetry: Instrument a bunch of functions.Wesley Aptekar-Cassels2025-11-241-1/+8
| | | | | These are all aimed at figuring out in more detail what's going on in #2079 and related issues.
* proto: Add a TODO relay for ChannelBuilderDavid Goulet2025-11-191-0/+2
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Make cargo doc happyDavid Goulet2025-11-191-2/+2
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Add client specific handshake channel structsDavid Goulet2025-11-191-1/+1
| | | | | | | | | | | | | | This adds the UnverifiedClientChannel and VerifiedClientChannel mirroring the relay API for channels. It plainly uses the generic object underneath as for now those objects are client only. Followup commits will make things more client specific. No behavior change. Signed-off-by: David Goulet <[email protected]>
* proto: Move client handshake into client channel moduleDavid Goulet2025-11-191-2/+9
| | | | | | | | | | | | | This only moves code from src/channel to src/client/channel. It introduces a ClientChanBuilder that is used to launch client specific channel by the public ChanBuilder. The followup commits will add a VerifiedClientChannel and UnverifiedClientChannel in order to again decouple client and relay code from the generic objects. Signed-off-by: David Goulet <[email protected]>
* proto: Add VerifiedRelayChannel implementationDavid Goulet2025-11-191-1/+2
| | | | | | | | Add the finish() function that for now simply calls the generic finish(). There is a bunch of TODO in the code in this commit explaining why we haven't made the implementation relay specific just yet. Signed-off-by: David Goulet <[email protected]>
* proto: Add UnverifiedRelayChannel implementationDavid Goulet2025-11-191-7/+0
| | | | | | | | | | | | | | This commits takes out the relay specific code out of UnverifiedChannel and puts it in UnverifiedRelayChannel. In order to pull this off, we added some fiels to the VerifiedChannel struct so the relay code get back generated data from the UnverifiedChannel::check() in order to do its validation work and yield a VerifiedRelayChannel. This also lead to a cleanup of expect() and ChannelType::is_initiator(). Signed-off-by: David Goulet <[email protected]>
* tor-proto: Reduce `high_water_mark` of ChannelFramenield2025-11-061-1/+3
|
* proto: Feature flag some relay specific codeDavid Goulet2025-10-231-0/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Compute authenticate data after validating certificatesDavid Goulet2025-10-231-1/+0
| | | | | | | | | | | | | | This is only done if we kept the AUTH_CHALLENGE cell and we have relay identities. In other words, this is only when the UnverifiedChannel was created from a RelayInitiatorHandshake. Note: The check_internal() function is too large and should be refactored in smaller pieces. Note: It is also likely that we need to split UnverifiedChannel and VerifiedChannel as it is getting client or relay members. Not great. Signed-off-by: David Goulet <[email protected]>
* proto: Add RelayInitiatorHandshakeDavid Goulet2025-10-231-0/+1
| | | | | | | This implements the relay initiator side of the handshake up to the creation of an unverified channel. Signed-off-by: David Goulet <[email protected]>
* proto: Change visibility for some channel objectsDavid Goulet2025-10-231-5/+5
| | | | | | | | | | Upcoming code for relay channels are put in the src/relay module and thus we need visibility into some channel generic things. Turns out also we don't need to re-export publicly UnverifiedChannel and VerifiedChannel. Signed-off-by: David Goulet <[email protected]>
* proto: Move celltypes out of clientGabriela Moldovan2025-10-131-1/+1
| | | | | Some of these are relay-specific, so it makes more sense to pull this into a top-level module.
* proto: experimental API to install a per-channel padder.Nick Mathewson2025-10-021-0/+30
|
* proto: start implementing logic for padding actions.Nick Mathewson2025-10-021-0/+1
|
* Add a blocker to channel outbound sink.Nick Mathewson2025-10-021-0/+7
|
* proto: Generate per-sender NormalSent events from circuits.Nick Mathewson2025-10-011-1/+7
|
* proto: Propagate PaddingCtrl into ChannelSender.Nick Mathewson2025-10-011-43/+68
| | | | We'll need it to tell the channel padder when padding is queued.
* proto: Add maybenot padding objects to the channel reactorNick Mathewson2025-10-011-0/+10
|
* Merge branch 'expire-halfstream-cbt' into 'main'gabi-2502025-09-241-1/+3
|\ | | | | | | | | | | | | proto: Remove half-streams when they expire. Closes #264 See merge request tpo/core/arti!3267
| * circmgr: Pass the timeout estimator to circuit constructor (fmt).Gabriela Moldovan2025-09-161-1/+1
| |
| * circmgr: Pass the timeout estimator to circuit constructor.Gabriela Moldovan2025-09-161-3/+2
| | | | | | | | | | This enables us to read the CBT estimates from the circuit reactor (we need these to compute the half-stream timeouts for #264).
| * proto: Use the CBT to compute half-stream timeouts.Gabriela Moldovan2025-09-161-0/+3
| |
* | proto::channel: Remove some statements about limitations.Nick Mathewson2025-09-171-6/+1
| | | | | | | | | | These have all become false, except for the one about being client-only, which is recapitulated at the crate level.
* | proto: Consider the channel queue with "Replace" padding to hop 1.Nick Mathewson2025-09-161-1/+0
| | | | | | | | | | | | | | | | | | When we want to send Replace padding (that is, padding that should only be sent if nothing else is queued) to hop 1, we can allow it to be replaced by cells from _any_ circuit being sent over the same channel. (Nobody but hop 1 can tell the difference.) Closes #2169
* | proto: for padding, count cells on each channel queues.Nick Mathewson2025-09-161-10/+60
|/ | | | We'll use this to implement `replace` for padding to the first hop.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 12:06:21 +0000