| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| |
|
|
|
|
| |
This logic from `create_firsthop()` was extracted (copied) from
`Reactor::run_once()`. A future commit will update `Reactor::run_once()`
to use `create_firsthop()`.
|
| |
|
|
|
| |
I don't know if these are needed because the rules are not documented
afaict. But it seems like probably they ought to be there?
|
| |
|
|
| |
These fns are in a feature-gated impls on feature-gated structs.
|
| |\
| |
| |
| |
| | |
clippy: Allow some of our existing code patterns
See merge request tpo/core/arti!1396
|
| | | |
|
| |\ \
| |/
|/|
| |
| | |
Overhaul send_control_message
See merge request tpo/core/arti!1367
|
| | | |
|
| | |
| |
| |
| | |
I think this name is fine.
|
| | | |
|
| | |
| |
| |
| | |
handle_msg is going to want this in a moment.
|
| | |
| |
| |
| |
| | |
If the circuit is just being used by us (which is likely, if we're
using this API) then the only reactor we're blocking is our own.
|
| | |
| |
| |
| |
| | |
We're going to want to do almost-the-same thing but without installing
a new handler.
|
| | |
| |
| |
| | |
Was send_control_message.
|
| | |
| |
| |
| |
| | |
We're going to let people start a conversation and either expect to
receive first, or send messages ad-hoc later.
|
| | |
| |
| |
| |
| |
| | |
Was UninstallHandler. We are going to talk more about conversations
and less about handlers (although, the fact of there being a handler
will still be visible).
|
| | |
| |
| |
| | |
Nothing else wants this and having it pub(super) is confusing.
|
| |/
|
|
| |
This appeases clippy-nightly.
|
| |
|
|
|
|
|
| |
We haven't generated these since Tor 0.3.5, which is no longer
supported on the network.
Closes #914.
|
| |\
| |
| |
| |
| |
| |
| | |
Better API for getting circuit paths
Closes #787
See merge request tpo/core/arti!1286
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
(I'm not 100% sure about having both hops() and iter(). Should I
remove one?)
|
| | |
| |
| |
| |
| |
| | |
The new PathEntry struct wraps the old PathEntry enum, which has
been renamed to HopDetail. It's an opaque struct because we want to
be able to put new information in the enum as we think best.
|
| | |
| |
| |
| | |
(You can't get one yet or do much with it.)
|
| | |
| |
| |
| |
| | |
Now Path is a regular struct with no interior mutability, and we use
Arc::make_mut() for the case when we need to add a hop.
|
| | |
| |
| |
| | |
(We're about to remove the interior mutability from Path.)
|
| | |
| |
| |
| | |
We never actually need to allow these again; see #914
|
| |/ |
|
| |
|
|
| |
Closes #887.
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1218#note_2908119
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Also, no longer talk about handlers being "installed". That's not
something that's exposed by this API.
And, say that `send_control_message` can be called again only
after *`send_control_message`* returns, not when `handle_msg` has
returned `UinstallHandler`. IMO this makes more sense.
Explain that we can't maintain a continuous watch while holding a
conversation with the peer. (This is surely an API bug.)
|
| |
|
|
|
| |
This fixes a warning when building tor-proto without the
`rpc-common` feature.
|
| |\
| |
| |
| |
| |
| |
| | |
tor-proto: Add support for extending circuits through virtual hops.
Closes #726
See merge request tpo/core/arti!1191
|
| | |
| |
| |
| |
| | |
Sadly, this adds a few more `TODO HS` entries, but I think we can
clean them up later after a bit of discussion.
|
| | |
| |
| |
| |
| |
| |
| | |
There are a few new TODO hs comments, though, and an XXXX I'll need
to fix up in the next commit.
Implements #726.
|
| | |
| |
| |
| |
| | |
This is fairly straightforward, thanks to our existing design work
on this code.
|
| |/
|
|
|
|
|
|
| |
- We make the tor-guardmgr "We have found that {} is usable" line
include the word "guard", otherwise it doesn't appear very useful to a
user in safe logging mode, since the guard gets replaced with
[scrubbed].
- The "Actually got an end cell..." message is downgraded to DEBUG.
|
| |
|
|
|
|
|
|
| |
If we didn't do this, we would need to transfrom
`EncodedLinkSpec`s into a `LinkSpec::Unrecognized`, which is not
semantically right. What's more, every user of this API wants to
consume encoded link specifiers, so encoding them early saves a
little effort.
|
| |
|
|
| |
This avoids some dead code warnings when building without send-control-msg.
|
| | |
|
| |
|
|
|
|
|
| |
(I found "user request" in one place, and fixed that. I am not
currently going to try to unify "control message" and "meta message"
since both terms are misleading and we already have TODOs to try to
merge them into a third better term.)
|
| |
|
|
|
| |
This way we don't need to worry about race conditions that happen if
the caller thinks that the handler is installed before it really is.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
This new function combines "sending a message" and "accepting
replies in a stream" into a single call, so that there is no gap
between when the message is sent and the replies are available.
There are a number of compromises here, in order to avoid API
proliferation. I've tried to contain them as best I can.
See comments for additional design discussion.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now, the MetaCellHandler is responsible for consuming the messages
it gets, and reporting status to whatever task is waiting for a
status message.
Additionally, the MetaCellHandler can decide to remain installed or
shut down the circuit after a successful message. (Previously, it
could only uninstall itself on success and kill the circuit on
failure.)
These changes will enable MetaCellHandlers to be used as the basis
for handling more kinds of message.
(There is some moved and reformatted code here; you may want to
review it with `git {diff or show} --color-moved -b`.)
|
| | |
|
| | |
|
| | |
|
