| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This comprises four renames:
```
write_onto -> write_onto_infallible
write_into -> write_into_infallible
write -> write_infallible
writer_and_consume -> write_and_consume_infallible.
```
The rest of this branch will be concerned with replacing these
`_infallible` methods with ones that return a `Result`. This is
part of #513.
|
| | | | |
| | | |
| | | |
| | | | |
This will help down the line as we make more writers fallible.
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | | |
tor-cell: Derive Eq for NtorV3Extension
See merge request tpo/core/arti!631
|
| | | | |
| | | |
| | | |
| | | | |
Apropos clippy complaint.
|
| |\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | | |
Make dormant be a postage::watch
See merge request tpo/core/arti!632
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In answer to
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/632#note_2822107
I think this is subtle enough that it deserves a comment.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This means that it is no longer possible to write code which updates
the dormant mode but forgets to notify the periodic tasks.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This will allow receivers (which we are about to introduce) to
terminate when the last client is dropped.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There are going to be some tasks (well, right away, one task) which
will want to go away when the sender is dropped.
The docs in postage are silent, but postage::watch::Sender does not
have a Drop impl so I don't think we can rely on the Receivers getting
None from their Stream impl.
So we're going to have the watch send Options, which are None only
when the sender is dropped.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We are going to want to be able to wake up other tasks elsewhere in
Arti, that need to know about dormancy. We will give them a postage
watch Receiver.
Right now there are no such things yet.
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
We're going to want this in a moment.
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We need to replace the AtomicBool for dormant mode with something that
can wake up tasks. postage::watch is the right shape.
But we want to be able to update it but suppress no-op updates.
(There is going to be a call site where no-op updates can occur.)
In the absence of a suitable upstream method as requested here
https://github.com/austinjones/postage-rs/issues/56
we introduce this facility via an extension trait.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Clean up some errors in tor-dirmgr
Closes #521
See merge request tpo/core/arti!628
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | | |
tor-persist: Resource::Temporary: Mark with cfg
See merge request tpo/core/arti!629
|
| |/ / /
| | |
| | |
| | | |
Without this, some builds get a "variant is never constructed" warning.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Clean-ups in circmgr errors
See merge request tpo/core/arti!625
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
We no longer needs to have a "return" at the end of each match
block.
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There's no reason to enforce their being Fn closures, and allowing
them to be FnMut allows us to count which filters make us rejected
given relays.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This interface allows using FilterCount with functions that expect
predicates rather than iterator chains.
I'm about to use it to get meaningful FilterCount results in the
path-selection code in circmgr.
|
| | | | | |
|
| | | |/
| |/| |
|
| | | |
| | |
| | |
| | |
| | | |
This does not require a change in any other crate, since
the change here does not affect tor-dirmgr's APIs.
|
| | | | |
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
Fix illegal formatting in cache filenames on Windows
Closes #516
See merge request tpo/core/arti!627
|
| |/ / |
|
| |\ \
| |/
|/|
| |
| | |
Fix some rustdoc links
See merge request tpo/core/arti!624
|
| | |
| |
| |
| | |
`NoLock` is now a variant of `err::ErrorSource` but that is private.
|
| |/
|
|
| |
This type must have been renamed, I guess.
|
| |\
| |
| |
| |
| | |
Implement a higher-level API for the ntor v3 handshake
See merge request tpo/core/arti!618
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This implements a higher-level API for the ntor v3 handshake, in line
with that exposed by the ntor handshake. It does not, however, use the
existing `ClientHandshake` trait, due to fundamental differences in the
handshakes (namely, that the v3 handshake can include some additional
extra extension data).
Currently, the higher-level API assumes circuit extension, and copies
the (undocumented!) magic verification string from c-tor that indicates
this usage.
A rudimentary set of functions for serializing and deserializing
extensions to be sent with the handshake is also included, implementing
the protocol in proposal 332 § A.2. Currently, it only implements the
congestion control extensions specified in proposal 324 § 10.3.
part of arti#88
|
| |\ \
| | |
| | |
| | |
| | | |
GuardMgr: Improve and revamp error types and messages.
See merge request tpo/core/arti!619
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This uses similar techniques to the commit I just did for Fallbacks.
|
| | | |
| | |
| | |
| | | |
Also re-order the filters to be a little more logical.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This is a helper rather than a Display implementation because it
isn't the only logical way to display these values. (In fact,
without context, it isn't even the _most_ logical way)
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is going to make it simpler to write the code in guardmgr (and
later in circmgr) that keeps track of how many relays were rejected
for what reason. The latter, in turn, should improve error messages
when we're unable to pick a guard or a path.
|