| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This restores the functionality of
socks users: detect closed sockets.
0c595818f713916d94b7b0e4062f953fad7c9799
which we reverted as part of rebasing this branch onto main.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This deduplicates some docs and eliminates the two wrapper functiosn
for `run_handshake`, which is now just `handshake`.
We're going to make other API breaks too, and this isn't going to be
the primary API, so we might as well do this.
Proper description of the semver breakage will come at the end when
it's all done.
|
| |
|
|
| |
This reverts commit 0c595818f713916d94b7b0e4062f953fad7c9799.
|
| |
|
|
| |
This reverts commit dceeb82f7d1154894ab9c7c607d68f8335bb9615.
|
| |\
| |
| |
| |
| | |
Miscellaneous cleanups, mostly in tor-memquota
See merge request tpo/core/arti!2461
|
| | |
| |
| |
| |
| |
| | |
Make it have a summary line of only reasonable size.
While we're here, wrap the body with semantic linefeeds.
|
| |\ \
| | |
| | |
| | |
| | | |
tor-chanmgr: support multiple channels for a relay ID
See merge request tpo/core/arti!2442
|
| | | | |
|
| | | |
| | |
| | |
| | | |
Like `ByRelayIds`, but allows multiple items per relay ID.
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
Upgrade dependencies in preparation for next week's releases.
See merge request tpo/core/arti!2450
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The `derive_more` crate broke backward compatibility with this version,
so this change involved quite a few manual fixups.
With luck, they'll keep compatibility for some while in the future.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When calling copy_within, we want to copy the amount of data that
we're keeping; previously, we were copying an extra `action.drain`
bytes, which could have led to a panic.
Spotted by Opara.
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| | |
Without this check, our socks code can enter an infinite loop
if a socket is closed at the wrong time.
Resolves TROVE-2024-011.
Fixes #1635.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
(And similarly rename TcpListener to NetStreamListener,
along with their TcpStream/TcpListener associated types.)
These types are about to become generic over addresses,
and therefore shouldn't be named after TCP.
Renaming was done mostly with Rust Analyzer,
except for some macros that needed to be hand-edited.
(I'll revise the comments in the next commit;
this one is all about renaming.)
|
| |/
|
|
|
|
|
|
|
|
| |
It's redundant with the incoming() method (which turns the
TcpListener into a Stream of connections), and nothing actually used
it outside of tests.
Removing this method allows us to simplify our TcpListener code a
good deal, as can be seen by some of the implementations we removed
from our example and testing code.
|
| |
|
|
|
|
|
|
|
| |
The channel manager in the future will need to be able to receive
incoming streams. The type of the stream depends on an associated type
within `ChannelFactory`, so this commit exposes this associated type
through several other types, eventually to the `ChanMgr`.
The new methods are behind the experimental "relay" feature flag.
|
| |
|
|
|
|
|
|
|
|
| |
This has two advantages:
1. Code is a little easier to follow with generics rather than dynamic
dispatch, especially since the type is fixed at compile time anyways.
2. It allows us to access associated types of the `ChannelFactory`,
which will be useful later for getting the stream type from the
`ChanBuilder`.
|
| |
|
|
|
| |
This allows us to set SRVs for example (needed because by default, the
test `NetDir` is built from a consensus that doesn't contain any SRVs).
|
| |
|
|
|
| |
Ticket #1509 will probably get rid of this constant,
but for now we may as well put it in one place.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having this in the `tor-async-utils` crate prevents us from doing both
of the following without introducing a circular dependency:
* using it in `tor-rtmock` (which we currently do, particularly in
tests).
* using `tor-rtmock` to test things in `tor-async-utils`. We don't do
this yet, but it is generally sensible to do so. In particular we
want to move the `stream_peak` module there, which is currently tested
with `tor-rtmock`.
Moving this into its own crate avoids this circular dependency.
|
| |\
| |
| |
| |
| | |
Proto: Refactor Channel to always be Arc.
See merge request tpo/core/arti!2163
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, Channel was a type that you could Clone that implicitly
its state. Now, Channel always appears as an Arc<Channel>.
This change has several benefits:
* It makes the relationship between Channel struct and the
underlying channel more clear.
* It enables Channel to participate in the RPC system,
where everything has to be an Arc<.>
* It enables us to have a Weak<Channel>, if we ever want to.
* It will let us move various members out of ChannelDetails.
We did this change a while ago with ClientCirc.
|
| |/
|
|
|
|
| |
(This isn't a bugfix, but it helps avoid the appearance of a
function calling itself. This _would_ become a bug if we imported
the wrong trait into scope here.)
|
| |
|
|
| |
This commit is automatically generated.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since Rust 1.66, std's default works properly for enums, provided that
the default variant is a unit.
Review all uses of `#[educe(default)]` on enums and replace them with
std where possible, which is most of them.
In 1.66 and later, std's `#[derive(Default)]` doesn't infer any
generic bounds on the derived impl, where it's an enum - since the
unit variant can always be constructed. So this change doesn't add
any generic bounds and is not API-visible.
|
| |
|
|
|
|
|
|
|
|
|
| |
This fixes a race condition that would normally be fairly benign -
it would result in scheduling to check for expired channels again
immediately, and assuming non-zero time passes would then remove the
channel.
In Shadow's default time model though, zero time passes in this case,
so we just keep scheduling to check again immediately forever; i.e.
deadlock.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Without this change, if the delay is less than one second, the code will
effectively busy-loop until the delay has elapsed. This
potentially leads to deadlock in shadow simulations, and
wastes CPU in real usage.
https://shadow.github.io/docs/guide/limitations.html?highlight=busy#busy-loops
|
| | |
|
| |
|
|
| |
cargo fmt, precisely.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|