| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
There are some tricky bits here that implicitly assume particular
behavior in other bits for correctness. Document these requirements and
assumptions.
Fixes arti#1373
|
| | |
|
| |
|
|
|
|
| |
The old code produced a warning from clippy nightly; we may as well
update to use the new associated consts. (They've been there since
Rust 1.4x.)
|
| | |
|
| | |
|
| |
|
|
| |
This is always Send+Sync, and invariant with P.
|
| |
|
|
|
| |
(We're letting the "unchecked" suffix of this function be enough
to indicate that it's risky to use.)
|
| |
|
|
|
|
|
|
|
|
| |
Instead of making `streammap.rs` responsible for keeping track of a
count field, this lowers that functionality into a lower-level
CountedHashMap type. Said type has a little more functionality than
we need, to sketch out how we'd want to develop it moving forward if
we find that it's useful elsewhere.
Closes #1344.
|
| | |
|
| |
|
|
|
|
|
|
| |
With this patch, it holds only a reference to `&reactor.hops`,
which greatly simplifies the reactor code's fight with the
borrow checker.
I've left some TODO comments about future directions here.
|
| |
|
|
| |
(Doing this to prevent us having two structs with the same name.)
|
| |
|
|
|
|
|
| |
Based on designs in #1124.
Note that there is a TODO here about a hack I had to do to appease
the borrow checker.
|
| |
|
|
|
| |
We'll use this as an argument for the callback that checks stream
requests to make sure they're permitted.
|
| | |
|
| |
|
|
|
|
| |
We want to keep an accurate count of the number of open streams, so
we have to stop exposing `&mut StreamEnt` outside of the streammap
module.
|
| |
|
|
|
|
|
| |
This is the first part of a refactoring that will let us keep code
from the outside of `streammap` from changing a stream from one
state to another. And we need to do _that_ so that StreamMap can
count how many open streams it has.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The key insights here are:
- That relay cell format and crypto protocols aren't orthogonal:
Once we have GCO, it will require V1.
- That we only need the actual functions for layer construction to
be generic; we don't need to proliferate generic parameters
everywhere.
- That the circuit::handshake module already does most of what we
want.
|
| |
|
|
|
|
| |
This lets us paramaterize types and functions by a particular relay cell
format. We use this e.g. to statically parameterize the cell crypto
functions, thereby removing some run-time branching in the hot path.
|
| | |
|
| | |
|
| |
|
|
|
| |
Different formats will use different ranges for the `recognized` and
`digest` fields.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Prop 340:
https://spec.torproject.org/proposals/340-packed-and-fragmented.html
This updates the decoding API to support multiple versions of the relay
cell encoding, including the new encoding proposed in prop340 that
supports relay message packing and fragmentation.
This commit doesn't actually add support for that new encoding yet.
|
| |
|
|
|
| |
For consistency with the terminology proposed in
https://gitlab.torproject.org/tpo/core/torspec/-/issues/253
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
`tor_circmgr::Error::Protocol` will soon include an optional `UniqId`.
Since `Protocol` errors can be caused by pending circuits, we need to be
able to peek at their `UniqId`.
Part of #1297
|
| |
|
|
|
|
|
|
| |
Some of the `tor_circmgr::Error` variants will include the `UniqId` of the
corresponding circuit, so we'll need to be able to display it without the
`Circ ` prefix.
Part of #1297
|
| |
|
|
|
|
|
| |
We never actually constructed these before, but now we enforce it at
the API level.
Part of #1269.
|
| |\
| |
| |
| |
| |
| |
| | |
Several clean-ups around failures in incoming stream request handlers.
Closes #1190, #1189, and #1188
See merge request tpo/core/arti!1892
|
| | | |
|
| | |
| |
| |
| | |
Closes #1190
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In theory, it might be better to just un-register the
IncomingStreamRequestHandler when the Receiver for the stream
requests is dropped. However, there are two reasons not to do so:
1. It's tricky. We never actually poll on the corresponding Sink,
so there isn't a place where the Reactor would expect to get a
prompt notification of closure. We only find out that the
Receiver has been dropped when an attempt to send on the Sink
returns an `is_disconnected` error.
2. It's unnecessary. In the Tor protocols, once we have decided to
accept incoming stream requests on a circuit, we want to continue
to do so until one of the parties closes the circuit.
I've documented this in several comments, in case whe want to get
fancier in the future.
Closes #1188.
|
| | |
| |
| |
| | |
Closes #1189.
|
| |/
|
|
|
|
| |
The bug described here was already fixed as #1065 via !1681.
Closes #1191.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
These are about making allow_incoming_streams give an error if a
handler is already installed.
I'm calling these non-MUST, since they don't affect the actual API
here, and we already have comments telling you not to do that. We
can add them later.
|
| | |
|
| |
|
|
|
|
|
| |
These comments are about internal representations and future extensions.
Also, add a fail-safe check to make sure that hop_num consistency is
enforced.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Filed
https://gitlab.torproject.org/tpo/core/arti/-/issues/1176
proposing a final fix.
|