| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| |
| |
| |
| | |
Expose and rename stream timeout config.
Closes #281
See merge request tpo/core/arti!231
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously we kept this in an ambiguously named type,
`ClientTimeoutConfig`. But everything we do right now is client
related! So `StreamTimeoutConfig` is a better name.
Also, we'd previously neglected to expose the builder for this type
from `TorClientConfigBuilder`. Now we do.
Closes #281.
|
| |/
|
|
| |
Closes #280.
|
| | |
|
| |
|
|
|
|
| |
See the new commentary text on `ClientCirc` for the rationale.
Signed-off-by: Ian Jackson <[email protected]>
|
| | |
|
| |\
| |
| |
| |
| | |
address clippy's latest lint
See merge request tpo/core/arti!205
|
| | | |
|
| |/
|
|
|
|
| |
We _do_ reject bad hostnames: just not where I once thought we might.
We need to decide if the current behavior is what we want (and I think
it is, probably?).
|
| |\
| |
| |
| |
| | |
Make most arti-client fields reconfigurable.
See merge request tpo/core/arti!181
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| | |
This covers ClientAddrConfig and ClientTimeoutConfig.
|
| | |
| |
| |
| |
| | |
(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. ;)
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
| | | |
|
| |/ |
|
| |
|
|
| |
We shouldn't have pub members in these config objects.
|
| |
|
|
|
|
|
| |
(There are other timeout rules, after all.)
Also, rename stream_timeout to connect_timeout, to make it more clear
when it applies.
|
| |\
| |
| |
| |
| | |
Usability: renaming and documentation in preemptive circuit config
See merge request tpo/core/arti!176
|
| | |
| |
| |
| |
| |
| | |
This obeys a few conventions:
* adjective before noun
* config objects end with "config"
|
| |\ \
| |/
|/|
| |
| |
| |
| | |
Make DNS fields in arti-client/src/client.rs configurable
Closes #252
See merge request tpo/core/arti!171
|
| | | |
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Allow configurability on preemptive circuits
Closes #245
See merge request tpo/core/arti!164
|
| | |/ |
|
| |/
|
|
|
|
|
|
| |
We want to only use TODO in the codebase for non-blockers, and open
tickets for anything that is a bigger blocker than a TODO. These
XXXXs seem like definite non-blockers to me.
Part of arti#231.
|
| |
|
|
| |
This makes sure that we're checking for a nonzero port in all cases.
|
| |\ |
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
The new CircMgr::build_circuits_preemptively function actually causes
preemptive circuits to be built; it gets called from arti-client, like
the other daemon tasks the CircMgr has.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The sane_defaults() call is now the same as you get from a default
builder: by convention, we just call that method Default::default().
The with_directories() constructor makes more sense as a constructor
for the TorClientConfigBuilder than for TorClientConfig.
|
| |\ \ \
| |_|/
|/| | |
|
| | | |
| | |
| | |
| | | |
(Also fix a couple of typos)
|
| | | |
| | |
| | |
| | |
| | | |
Make sure that we can change elements, and we can reconstruct builders
that give us the same thing.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
When we deserialize a configuration, we should reject unknown variables
(except when we have an explicit reason to allow them).
|
| | | |
| | |
| | |
| | | |
These don't need to be exposed any longer.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I'm still not 100% sure this is the right move: should we encourage
app developers to always pick their own directories? Or should we
make it easy for them to use, well, `sane_defaults`?
This patch takes the second approach.
|
| | | | |
|
| |/ / |
|
| | | |
|
| | | |
|
| |/
|
|
| |
Also fix some commonwealth spellings that had slipped in.
|