| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
When making sure that the peer had the right RSA identity, we
were comparing the RSA identity with itself, not with the RSA
identity we expected.
Found via unit testing (!).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
They're supposed to be called field_mut().
|
| |
|
|
|
| |
According to the API guidelines, "as_" is only for
borrowed->borrowed conversions.
|
| | |
|
| |
|
|
|
|
|
|
| |
These aren't called "close" because they're more destructive than
that: they can be called even if other parties are using the circuit
or channel.
This is for arti#21.
|
| | |
|
| | |
|
| |
|
|
|
| |
We need to make sure that we're dropping cells that we don't
recognize or want, so that we can't be flooded with bogus junk.
|
| | |
|
| | |
|
| |
|
|
|
| |
These traits are inverses of one another, but implementing From is
always preferred since rust 1.41 relaxed the "orphan rules".
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Now, a Relay is always valid. This required some changes to the
API: all_relays() has to return a new UncheckedRelay type that might
or might not be valid, and the functions on Relay and ChanTarget
that return ed25519 identities need to return an Ed25519Identity,
not an ed25519::PublicKey.
This change required some new encoding/decoding/conversion functions
on Ed25519Identity.
|
| |
|
|
|
|
|
|
|
|
| |
"M3" is for "milestone 3" -- my target to fix the technical debt
that I think will be bad if we ship even a pre-alpha with it.
These aren't necessarily _all_ must-resolve, but they're all
must-look-at.
Closes #15
|
| |
|
|
|
|
| |
This wraps exactly the ChanMsg values that are valid on open client
circuits, so that we can be sure that only those cells are sent to a
ClientCirc's reactor.
|
| |
|
|
|
|
| |
CreateResponse includes exactly those cells that are a correct
response to a CREATE2/CREATE_FAST, so we can be sure that only those
cells are actually passed to a PendingClientCirc.
|
| | |
|
| |
|
|
|
| |
This way, when the channel reactor is dropped, the circuit map
can get dropped too, which will cause reading circuits to notice.
|
| |
|
|
|
| |
Similarly as with circuits, we want this code to set a "closed" flag
so that attempts to write on the channel will fail.
|
| |
|
|
| |
This prevents the reactor from keeping the circuit alive forever.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This reuses a lot of mechanism from the circuit code that sends END
cells when streams are dropped.
There is a problem here: Circuits and channels won't actually get
dropped, because we should be using a weak reference from the
reactor.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
We already handled the case okay when we were reading on streams,
since the reactor's going away would drop the sender side of their
mpsc channels. But if the reactor went away, nothing would tell
_writing_ streams that they needed to close.
Now we handle that case, as well as anybody who is waiting on
a meta-cell to get back to them.
|
| |
|
|
|
|
| |
When a stream is closed and we haven't adjusted its state in the
stream map yet, remember how many cells we've dropped so we can
decrement them from the window later on.
|
| |
|
|
|
|
| |
This is the first step along the line to handling Tor issue
tor#27557. We want to remember streams that we've ended and treat
them as distinct from streams that have never existed
|
| |
|
|
|
| |
These need to become functions about terminating and noticing a
termination request.
|
| |
|
|
| |
This is in preparation for adding a different EndSent stream state.
|
| |
|
|
|
|
|
|
|
| |
The problem is that we would count begin and end cells towards
towards window totals when we are only supposed to count DATA
cells, *and* that we would we send our sendmes one cell too early
(or maybe late?).
Closes #1.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the circuit object owned not only the outbound crypto,
but also the inbound crypto and the stream maps. That's not so
great, since the reactor needs to use the inbound crypto and the
stream maps all the time, whereas the circuit doesn't need them much
(or at all).
Moving these objects to the reactor-owned structure should let us
fix the deadlock case in stream sendme handling, since the circuit
reactor no longer needs to lock the circuit in order to do crypto
and demultiplexing. It should also speed up the code a bit, since
it doesn't need to grab the circuit lock nearly so often as before.
This change forced me to add a couple of new reactor CtrlMsg values,
since the circuit can no longer add streams and layers directly. I
think it will still be a performance win, though.
|
| |
|
|
|
| |
I think we should have the reactor task own the reverse crypto and
the circuit own the forward crypto.
|
| | |
|
| | |
|
| | |
|
| | |
|