summaryrefslogtreecommitdiff
path: root/crates/tor-chanmgr/src/lib.rs
Commit message (Collapse)AuthorAgeFilesLines
* Abolish ChanMgr::set_default_transportIan Jackson2022-11-301-13/+0
| | | | | | The comment says // TODO pt-client: It's not clear to me that we really need this method. and empirically, deleting it, and its callee, is fine.
* Fix ChanMgr APIs for setting PtMgr etc to match what TorClient wants.Nick Mathewson2022-11-281-7/+4
|
* tor-chanmgr: Introduce the BootstrapReporter API, publicize ChanBuildereta2022-11-281-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | This commit makes the `ChanBuilder` type in `tor-chanmgr` usable by consumers outside of that crate, like the doc comment for `ChannelFactory` says you need to be able to do in order to turn your `TransportHelper` into something useful. As part of doing this, the `event_sender` its constructor takes needed to be dealt with, since it was a crate-internal type that came from inside the `ChanMgr`. Enter `BootstrapReporter`: an opaque wrapper around that sender, now provided as an additional argument to `ChannelFactory::connect_via_transport`. You can now construct a `ChanBuilder` outside this crate, and it'll still be able to report its bootstrap status by unwrapping this new type that's threaded through from the `ChanMgr`. (This was a fair deal of manually threading the type through all the layers in this crate!) Note that you cannot implement bootstrap updating using something that isn't `ChanBuilder` yet due to the type being entirely opaque (but, of course, we can figure out exactly what API the reporter should have later, and add that capability in).
* ChanMgr: Rename Factory -> CompoundFactoryNick Mathewson2022-11-231-2/+2
|
* Mark set-default-factory API as experimental.Nick Mathewson2022-11-231-4/+2
|
* Make ChannelFactory and AbstractPtMgr require Send+SyncNick Mathewson2022-11-231-1/+1
|
* ChanMgr: Implement functions that replace channel factories.Nick Mathewson2022-11-231-15/+20
| | | | | | | This commit makes it possible to replace the default channel factory (used when there is no PtMgr), and to replace the PtMgr. This is part of #659.
* ChanMgr: move the AbstractChanFactory into MgrState.Nick Mathewson2022-11-221-3/+3
| | | | | | We will want the freedom to replace this, so it needs to go behind a lock. We need to be able to Clone it cheaply now, so we're using an Arc instead of a Box.
* Replace TransportRegistry with AbstractPtMgreta2022-11-221-3/+3
| | | | | | | | | | | | | | | | | | It doesn't make much sense to have the pluggable transport manager be a registry, so replace its interface with a more narrowly defined, less generic version. Other changes: - instead of returning a &-reference, it returns an owned Arc, which should make the ptmgr easier to implement while allowing efficient reuse - provision for error handling is added, but will probably be revised in a future commit pending discussion - tor-ptmgr code that would generate warnings as a result of this change is temporarily removed This is a split out version of arti!886, intended so work on arti#659 can proceed.
* Run add_warnings.Nick Mathewson2022-11-031-0/+1
|
* chanmgr: Remove "Ident" from AbstractChannelNick Mathewson2022-10-181-10/+1
| | | | | Thanks to our previous changes, we no longer need this type, or the methods that access it.
* ChanMgr: Reorganize factory, builder, transport code.Nick Mathewson2022-10-131-1/+2
| | | | There is no actual code change here: just movement.
* Merge branch 'factory_redux' into 'main'Nick Mathewson2022-10-131-5/+20
|\ | | | | | | | | chanmgr: Build and use chanmgr factory APIs See merge request tpo/core/arti!769
| * Flatten TimeoutChannelFactory into ChannelBuilder.Nick Mathewson2022-10-131-2/+1
| |
| * chanmgr: clean up some TODO pt-client items and documentation.Nick Mathewson2022-10-131-2/+5
| |
| * Allow multiple ChannelBuilders to share a ChanMgrEventSender.Nick Mathewson2022-10-131-0/+1
| |
| * chanmgr: Use ChannelFactory via a Box<dyn<ChannelFactory>>.Nick Mathewson2022-10-131-4/+12
| | | | | | | | | | This will prepare for supporting multiple different ChannelFactory implementations.
| * chanmgr: Move Timeout functionality into a decorator object.Nick Mathewson2022-10-131-2/+5
| |
| * Have ChannelBuilder use TransportHelper.Nick Mathewson2022-10-131-2/+3
| | | | | | | | | | | | This lets us build channels using different TransportHelpers, including the (new) default TransportHelper, which just uses the old connect_to_one() code.
* | cargo fmt to remove blank linesIan Jackson2022-10-121-1/+0
| | | | | | | | | | | | | | Apparently cargo fmt doesn't like these, which my perl rune didn't delete. This commit is precisely the result of `cargo fmt`.
* | Replace all README copies in src/lib.rs with includesIan Jackson2022-10-121-33/+1
|/ | | | | | | | The feature we want is `#[doc = include_str!("README.md")]`, which is stable since 1.54 and our MSRV is now 1.56. This commit is precisely the result of the following Perl rune: perl -i~ -0777 -pe 's{(^//!(?!.*\@\@).*\n)+}{#![doc = include_str!("../README.md")]\n}m' crates/*/src/lib.rs
* Mark all bridge and pt features as experimental for now.Nick Mathewson2022-09-291-0/+17
| | | | | | Also, document the features. Closes #588.
* ChanMgr: new (unimplemented) APIs for pluggable transportsNick Mathewson2022-09-231-0/+21
|
* Improve docs for ChannelUsageNick Mathewson2022-09-221-7/+15
| | | | | | | Try to clarify more that the ChannelUsage is for describing the usage for one particular channel request, not for the channel as a whole. This is a potentially confusing point, so we should spell it out completely.
* enable doc_auto_cfg feature on every crate when documenting for docs.rstrinity-1686a2022-08-241-0/+1
|
* channel usage: Rename CU::UserTraffic from CU::ExitIan Jackson2022-08-171-1/+1
| | | | | As suggested in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2827246
* Improve comment for ChannelUsage::ExitNick Mathewson2022-08-171-1/+1
|
* Move ChannelUsage from tor_proto to tor_chanmgrIan Jackson2022-08-171-1/+23
| | | | | | | | | | | Replace Channel::note_usage with Channel::engage_padding_activities, which unconditionally causes the channel to (start to) do netflow padding things. The condition now lives in chanmgr. Addresses https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826094
* chanmgr: Use NetDirProvider::params and Arc<dyn..Netparameters>Ian Jackson2022-08-171-9/+14
| | | | | | | | | This gets rid of many Result(). Many parameters are renamed. Test cases of the now-impossible branch are removed. Deleting the match from padding_parameters will come in a moment. I've split off that commit since it has much whitespace noise. for now, change the error type to Void.
* chanmgr set_dormancy: Remove obsolete commentIan Jackson2022-08-171-4/+0
|
* chanmgr: Extend doc comments for DormancyIan Jackson2022-08-171-0/+6
| | | | | Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2825962
* Fix typos in comments.eta2022-08-171-1/+1
|
* chanmgr configuration: Hadle lack of a NetDirIan Jackson2022-08-161-1/+0
| | | | | | Now that the code that actually handles the netdir information can cope with its lack, we can change the types of the various netdir parameters and get rid of the foolish Bugs.
* Introduce ChannelConfigIan Jackson2022-08-161-2/+22
| | | | | This commit is just the necessary plumbing. The config is currently empty. We'll add something to it, for padding control, later.
* Provide ChannelUsage and plumb it all the way downIan Jackson2022-08-161-2/+6
| | | | | | | | | | | | | Channel padding depends on what the channel is being used for. We therefore need to let the channel code know this information. The implementation of the per-channel padding control logic will be in the new note_usage function, which for now is simply a stub. A future commit will introduce a `PaddingControlState` which lives in the channel frontend; consult the doc comment for that type to see why the plumbing through the channel manager terminates in the channel frontend.
* dormancy: Plumb through to chanmgr reconfigure_generalIan Jackson2022-08-161-3/+30
| | | | | | | | | | | | | | | The chanmgr remembers the last dormancy state it was told. We invent a chanmgr-specific Dormancy which the arti-client code knows how to convert from the richer top-level dormant status. This avoids having to have everyone know all the variants of the top-level state. To call reconfigure_general, we must also obtain and plumb through a netdir. Right now we must return an internal error if there is in fact no netdir, because reconfigure_general does not yet cope with a missing netdir. Nothing actually *uses* the dormancy yet.
* chanmgr: reconfigure_general: Rename fn and change typesIan Jackson2022-08-161-1/+1
| | | | | | | | | | | | | | | This function is going to become the code for controlling channels, in general. (Including padding control.) Right now it doesn't do most of the things. In this commit: * Change the prototype and the name now. * Pass `()` for the dormancy and config, adding TODOs. * Provide update_netdir method on AbstractChanMgr, and call that, rather than having the ChanMgr go directly into the channel. (That will enable us to test that `update_netdir` method with test cases that don't have a complete ChanMgr.)
* Final (?) API revisions for tor-linkspecNick Mathewson2022-08-101-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this change, each individual identity type becomes optional. The functions that expose them unconditionally are now in a "legacy" trait that only some downstream types are expected to implement. There are new convenience APIs in HasRelayIds: * to return Option<&keytype>, * to see if one identity-set contains another. This commit will break several downstream crates! For the reviewer's convenience, I will put the fixes for those crates into a series of squash! commits on this one. tor-netdir ---------- Revise tor-netdir to accept optional identities. This required some caveats and workarounds about the cases where we have to deal with a key type that the tor-netdir code does not currently recognize at all. If we start to add more identity types in the future, we may well want more internal indices in this code. tor-proto --------- In order to make tor-proto support optional identities, there were fewer changes than I thought. Some "check" functions needed to start looking at "all the ids we want" rather than at "the two known IDs"; they also needed to accommodate that case where we don't have an ID that we demand. This change will also help with bridges, since we want to be able to connect to a bridge without knowing all of its IDs up front. The protocol currently _requires_ the two current ID types in some places. To deal with that, I added a new `MissingId` error. I also removed a couple of unconditional identity accessors for chanmgr; code should use `target().identity(...)` instead. tor-chanmgr ----------- This is an incomplete conversion: it does not at all handle channel targets without Ed25519 identities yet. It still uses those identities to index its internal map from identity to channel; but it gives a new `MissingId` error type if it's given a channel target that doesn't have one. We'll want to revise the map type again down the road when we implement bridges, but I'd rather not step on the channel-padding work in progress right now. tor-guardmgr ------------ This change is mostly a matter of constructing owned identity types more sensibly, rather than unwrapping them directly. There are some places marked with TODOs where we still depend on particular identity types, because of how the directory protocol works. This will need revisiting when we add bridge support here. tor-circmgr ----------- These changes are just relatively simple API changes in the tests.
* ChanMgr: Only update parameters from a timely directory.Nick Mathewson2022-07-261-2/+2
|
* ChanMgr: Add more contextual info to error types.Nick Mathewson2022-07-061-1/+1
| | | | | | Now each type has a peer. In some cases this peer is just an address, whereas in others (where key is relevant or address isn't yet narrowed down) it's a full OwnedChanTarget.
* Run maint/add_warning crates/*/src/{lib,main}.rsIan Jackson2022-06-231-0/+3
| | | | Update all lint blocks
* tor-chanmgr: Change to use unwrap_voidIan Jackson2022-06-211-8/+4
| | | | | As per discussion in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2813573
* channel padding: Plumb settings from chanmgrIan Jackson2022-06-211-3/+66
|
* lints: Add let_unit_value allow to all cratesIan Jackson2022-05-311-0/+1
| | | | | From running add_warning, with manual picking of the right hunks/lines.
* lints: Add lint block delimiters to every crateIan Jackson2022-05-311-0/+2
| | | | | | This was the result of: maint/add_warning crates/*/src/{lib,main}.rs and then manually curating the results.
* ChanMgr: Return provenance information from get_or_launchNick Mathewson2022-04-071-3/+17
| | | | | | We need this since we want to report certain conditions only when they happen on a new channel, not if we observe them on a preexisting channel.
* chanmgr: bubble ClockSkew up through the Error object.Nick Mathewson2022-04-071-1/+2
| | | | | | | | Fortunately, we don't need a separate type here: authenticated clock skew can only come attached to a `tor_proto::Error`. We also remove skew from `tor_proto::Error::HandshakeCertsExpired`, since it would now be redundant.
* Make daemon tasks self-contained; introduce NetDirProvidereta2022-03-301-0/+41
| | | | | | | | | | | | | | | The various background daemon tasks that `arti-client` used to spawn are now handled inside their respective crates instead, with functions provided to spawn them that return `TaskHandle`s. This required introducing a new trait, `NetDirProvider`, which steals some functionality from the `DirProvider` trait to enable `tor-circmgr` to depend on it (`tor-circmgr` is a dependency of `tor-dirmgr`, so it can't depend on `DirProvider` directly). While we're at it, we also make some of the tasks wait for events from the `NetDirProvider` instead of sleeping, slightly increasing efficiency.
* Disable clippy::clone_on_ref_ptrIan Jackson2022-02-241-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This lint is IMO inherently ill-conceived. I have looked for the reasons why this might be thought to be a good idea and there were basically two (and they are sort of contradictory): I. "Calling ‘.clone()` on an Rc, Arc, or Weak can obscure the fact that only the pointer is being cloned, not the underlying data." This is the wording from https://rust-lang.github.io/rust-clippy/v0.0.212/#clone_on_ref_ptr It is a bit terse; we are left to infer why it is a bad idea to obscure this fact. It seems to me that if it is bad to obscure some fact, that must be because the fact is a hazard. But why would it be a hazard to not copy the underlying data ? In other languages, faliing to copy the underlying data is a serious correctness hazard. There is a whose class of bugs where things were not copied, and then mutated and/or reused in multiple places in ways that were not what the programmer intended. In my experience, this is a very common bug when writing Python and Javascript. I'm told it's common in golang too. But in Rust this bug is much much harder to write. The data inside an Arc is immutable. To have this bug you'd have use interior mutability - ie mess around with Mutex or RefCell. That provides a good barrier to these kind of accidents. II. "The reason for writing Rc::clone and Arc::clone [is] to make it clear that only the pointer is being cloned, as opposed to the underlying data. The former is always fast, while the latter can be very expensive depending on what is being cloned." This is the reasoning found here https://github.com/rust-lang/rust-clippy/issues/2048 This is saying that *not* using Arc::clone is hazardous. Specifically, that a deep clone is a performance hazard. But for this argument, the lint is precisely backwards. It's linting the "good" case and asking for it to be written in a more explicit way; while the supposedly bad case can be written conveniently. Also, many objects (in our codebase, and in all the libraries we use) that are Clone are in fact simply handles. They contain Arc(s) (or similar) and are cheap to clone. Indeed, that is the usual case. It does not make sense to distinguish in the syntax we use to clone such a handle, whether the handle is a transparent Arc, or an opaque struct containing one or more other handles. Forcing Arc::clone to be written as such makes for code churn when a type is changed from Arc<Something> to Something: Clone, or vice versa.
* Change deny(clippy::all) to warn(clippy::all).Nick Mathewson2022-02-141-1/+1
| | | | Closes #338.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 05:34:22 +0000