| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Done using:
```
for crate in $(./maint/list-crates | rg '^(tor|arti-)'); do
cargo set-version -p $crate 0.43.0
done
```
|
| |\
| |
| |
| |
| | |
proto: Replace outdated references to RawCellStream
See merge request tpo/core/arti!4036
|
| | |
| |
| |
| |
| | |
`RawCellStream` was removed long ago, in
c559754116678866eabe525f5b189b50cc78b5cc.
|
| |/
|
|
|
|
| |
`/channel/handler.rs`
Closes #1690.
|
| |\
| |
| |
| |
| | |
proto: Add tests for DESTROY and TRUNCATE handling
See merge request tpo/core/arti!4008
|
| | |
| |
| |
| |
| |
| | |
We decided the reactor is the wrong place to handle this.
See discussion in #2490
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds an extra assertion that ensures the relay reactor does in fact
send an EXTENDED2 on its towards-the-client channel after receiving the
CREATED2 response from the fake hop.
This check is nice to have in general, but the main reason I'm doing
this now is because for the DESTROY tests I'm about to add, I need the
inbound MPSC queue (towards the client) drained of these handshake
messages in order to check that the "next" cell we've sent is a destroy.
I could've added some custom code to drain it just for the purposes of
that test, but I think it's better to have `do_create2_handshake()` take
care of it.
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
The new name is (hopefully) a bit more descriptive.
I'm planning on extending this function soon to support checking if a
DESTROY has been sent on the outbound channel too, so I'm tweaking the
docs a bit in preparation for that.
|
| | |
| |
| |
| | |
I'll soon need this for a DESTROY test.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This changes a debug log to have the same format as the corresponding
DESTROY-related log from the forward reactor.
Part of #2490
|
| | | |
|
| | |
| |
| |
| | |
Part of #2490
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Set socket buffer sizes (`SO_SNDBUF` and `SO_RCVBUF`) for proxy sockets
Closes #2500
See merge request tpo/core/arti!3957
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This better matches nearby code.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously when initializing a stream, we constructed most of the
stream-related queues outside of the reactor and passed the relevant
halves of the queues (senders or receivers) into the reactor.
A downside of the above approach is that the reactor may be better
informed about what queues to construct, and how to construct them. For
example the reactor knows what type of flow control that the hop is
using, so it knows whether we need queues for passing rate limits and
drain rates for XON/XOFF flow control.
This commit moves the construction of these queues into the reactor and
passes the relevant halves out of the reactor. In the future we can make
better decisions about which queues are needed depending on the flow
control method used instead of always constructing them (see arti#2068).
Reviewing with `--color-moved` might be helpful as a few lines have been
moved.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Whether a stream queue should be bounded or unbounded is a decision that
needs to be made at runtime depending on the type of flow control used,
not at build-time. Window-based flow control should be bounded and
XON/XOFF flow control should be unbounded.
If we wanted to support both bounded and unbounded queues, it would take
a bunch of boilerplate code to wrap the senders and receivers in enums.
Instead we make the queue always bounded, but use a large bound for
XON/XOFF flow control.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The stream queue length (for messages incoming from the Tor network)
depends on the type of flow control we're using for the hop. Currently
we construct the stream queue outside of the circuit reactor, but we
don't have the flow control information here.
Instead of constructing the stream queue outside of the reactor and
passing the sender into the reactor, we construct the stream queue
inside of the reactor and pass the receiver out of the reactor.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
The common suffix isn't needed.
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
tor-proto: Don't run vegas algorithm when a clock stall/jump was detected
Closes #2504
See merge request tpo/core/arti!3967
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When the circ-padding feature is enabled, we use maybenot, which does
not yet support rand 0.10. In the meantime, enabling this feature pulls
in rand 0.9. This is not ideal, but should be okay as a temporary
situation.
This also replaces the use of ReseedingRng (which was removed in 0.10)
with the reseeding_rng crate. This is somewhat less performant, but it
should be okay.
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This moves the window-based flow control for half-streams out of the
`HalfStream` and into the `HalfStreamWindowFlowCtrl` object.
Now that it's applied only in `HalfStreamWindowFlowCtrl` and not
generally for all half-streams, we no longer apply window-based flow
control to half-streams when they're really using xon/xoff-based flow
control.
|
| | |
| |
| |
| |
| | |
This adds the general structure, and we'll fill it in and use it in a
following commit.
|
| |/ |
|
| | |
|
| |\
| |
| |
| |
| | |
release: Version bumps
See merge request tpo/core/arti!3952
|
