| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\ \ \ \ |
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | |/ /
| |/| | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Always check whether stream-level SENDMEs are expected.
Closes #261
See merge request tpo/core/arti!192
|
| | |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
(It's a protocol violation to get a SENDME when our send window is
already full.)
This patch makes SendWindow::put return a Result, so that it's
easier to do the right thing with it.
Closes #261.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
proxy: introduce new functions to write_all & flush/close
Closes #262
See merge request tpo/core/arti!199
|
| | | |/ /
| |/| |
| | | |
| | | | |
Signed-off-by: Muhammad Falak R Wani <[email protected]>
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Remove unused started_at in PendingRequest
See merge request tpo/core/arti!196
|
| | | | | |
|
| |\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
tor-chanmgr: Fix happy eyeballs comment grammar in builder.rs
See merge request tpo/core/arti!197
|
| |/ / / |
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
Actually decrement the stream-level SENDME window
Closes #260
See merge request tpo/core/arti!194
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
arti!126 overhauled the `tor-proto` circuit reactor, but left out one
very important thing: actually decrementing the SENDME window for
streams (not circuits) when we send cells along them.
Since the circuit-level SENDME window would often prevent us from
running into a problem, this wasn't caught until my benchmarking efforts
noticed it (in the form of Tor nodes aborting the circuit for a protocol
violation).
fixes arti#260
|
| |\ \ |
|
| | | |
| | |
| | |
| | | |
Signed-off-by: Muhammad Falak R Wani <[email protected]>
|
| |\ \ \ |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | |/ / |
|
| | |/
|/| |
|
| |\ \
| | |
| | |
| | |
| | | |
Make most arti-client fields reconfigurable.
See merge request tpo/core/arti!181
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
We join "state" to the directory name, so we must call parent() to get
the original.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
This is still not as soon as I'd like: a real change here will require
refactoring DirMgr::notify().
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We don't want MutCfg to be automatially coneable, or we'll wind up with
surprises like the one that this patch fixes in TorClient.
(The "surprise" is that reconfigure() would only apply its
client-specific options to one client instance.)
|
| | | |
| | |
| | |
| | |
| | |
| | | |
If we allow overlapping reconfiguration requests, we introduce all
kinds of "fun" bugs. For example, we could wind up with a configuration
made up of parts of one reconfiguration attempt, and parts of another.
|
| | | |
| | |
| | |
| | |
| | | |
It no longer makes sense to say "most things can't change", now that
most things can.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We can't change the authorities while in-flight: that would be pretty
miserable to implement.
Similarly we can't change the cache while in-flight.
Everything else should be fair game, though there are a couple of tricky
bits. I've tried to document those.
|
| | | |
| | |
| | |
| | | |
This covers ClientAddrConfig and ClientTimeoutConfig.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Most notably, make min_exit_circs_for_port actually get used.
Also add a couple of comments.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This required re-centralizing the configuration object for preemptive
circuits, since previously the settings from it were a bit spread out
over the crate.
|
| | | |
| | |
| | |
| | |
| | | |
This will help in the case when a configuration can only partially
change.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
(These weren't in the codebase when I started the first version of
this branch.)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
And now the complexity begins: when the user changes the path_rules,
they not only want new circuits to obey those rules: they want
_all new requests_ to be put onto circuits that obey those rules.
That means that when the path rules become more restrictive, we need
to retire all the circuits, and make sure that currently pending
circuits aren't used for any requests.
If it's any comfort, doing this was even more complicated in C tor. ;)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It's useful to keep configuration objects inside a RwLock<Arc<>>, so we
can have slightly-stale pointers to the existing configuration structure
without holding locks too long.
This code adds a MutCfg type with basic support for this pattern,
and functions to make it a bit more ergonomic.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This patch doesn't actually make anything reconfigurable, but it
does create an API that will tell you "you can't change the value of
that!" If the API looks reasonable, I can start making it possible
to change the values of individual items.
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
Don't create circuits if the consensus is stale by over 72 hours
Closes #89
See merge request tpo/core/arti!190
|
| |/ / |
|
| | |
| |
| |
| |
| | |
[Edited by nickm: This applies one of Daniel's fixes in place of one
of Trinity's: Trinity says it's a bit cleaner, and I agree.]
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
[T;N] supports TryFrom<Vec<T>>, and has since Rust 1.48: we can just
use that.
This resolves an XXXX comment.
|
| | | |
|
| | |
| |
| |
| | |
These issues all have tickets, so can become TODOs.
|