| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Fixes part of #2193.
(Edits from nickm: I selected the cases here that I could verify
were correct from immediate context.)
Edited-by: Nick Mathewson <[email protected]>
|
| |\
| |
| |
| |
| | |
proto: Start handling incoming streams in the relay reactor
See merge request tpo/core/arti!3487
|
| | |
| |
| |
| | |
All this indirection is making me dizzy.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is needed because we want to reuse `StreamTarget` and `DataStream`
on the relay side too, but to do that, we need to abstract away the
tunnel/circuit type (prior to this MR, `StreamTarget` was was
client-specific, as it used to wrap a client tunnel).
Note that `StreamTarget` needs a handle to the client/relay circuit
reactor because it needs to be able to shut down the circuit if a
protocol error occurs (cells carrying stream data are parsed late,
*outside* of the reactor, so if e.g. a cell fails to parse, the
`DataReaderImpl` needs to be able to shut it down), and because it needs
to be able to inform the reactor of flow control-related events (such as
drain rate update).
|
| | |
| |
| |
| | |
For relays, the hop of the StreamTarget will be set to `None`.
|
| | | |
|
| | |
| |
| |
| | |
We are about to use `StreamReqInfo` for exit streams too.
|
| |/
|
|
|
| |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This only moves code from src/channel to src/client/channel.
It introduces a ClientChanBuilder that is used to launch client specific
channel by the public ChanBuilder.
The followup commits will add a VerifiedClientChannel and
UnverifiedClientChannel in order to again decouple client and relay code
from the generic objects.
Signed-off-by: David Goulet <[email protected]>
|
| | |
|
| |
|
|
| |
This is part of an implementation for proposal 368.
|
| | |
|
| |
|
|
| |
These will be shared with the relay code.
|
| |
|
|
|
|
| |
That way we don't need to make halfstream `pub(crate)` (we only really
use it in streammap, and in the client reactor, because of the
`handle_msg()` kludge).
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
We need it for exits and leaky pipe.
Part of #2212
|
| | |
|
| |
|
|
|
|
| |
The previous "incoming" terminology was rather ambiguous.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3348#note_3275337
|
| | |
|
| |
|
|
|
| |
This makes it easier to see which parts are implementation-agnostic
(i.e. do not import from crate::client).
|
| | |
|
| | |
|
| |
|
|
| |
This will be used by exits too, so I am moving it out of `client`.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For now, we're not going to implement hop negotiation: we're still
waiting to find a set of padding machines that will be useful for
Arti. This API will help facilitate experimentation to find such
padding machines.
These APIs are under a separate feature (`circ-padding-manual`)
to avoid confusing them with the rest of the padding code:
we only want them to be exported when the researcher wants to
manually install circuit padding.
|
| |
|
|
|
| |
For internal types, I think it becomes too much of a mess to export
everything through a single module.
|
| |
|
|
| |
This is all private (or pub(crate)) code.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The `TunnelId*` types will be reused in the relay reactor (exit relays
need to have the concept of a "tunnel ID" because of conflux).
Now the `relay::reactor` module only has a single import from `client`
(for the `unwrap_or_shutdown` helper, which we should be able to remove
soon). From now, we will avoid importing anything from `client` in the
`relay` module, and instead prefer refactoring the code as needed (to
pull the implementation-agnostic parts outside of `client`).
This commit has no functional changes, just code motion.
|
| |
|
|
|
|
|
| |
This is just code motion (I suggest reviewing with `--color-moved`).
This also moves the implementation-agnostic parts from
`tor_proto::client::circuit` to a new `tor_proto::circuit` module.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The `stream` module is client-specific, for the most part, so I am
moving it under `client`. Later on, we will factor out the parts that
can be shared with the relay implementation.
Note: this is a breaking change as the deleted `stream` module was
`pub`. We could've kept the module and reexported from it the public
types from `tor_proto::client::stream`, but I think it's better to have
this `client` namespacing, because it makes the separation between the
client and relay parts clearer.
|
| | |
|
|
|
The implementation from `tunnel` is client-specific, so we are renaming
the module accordingly. The more generic parts will be pulled into a
separate module in a future commit.
|
