| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
By convention, rust accessor functions don't start with 'get'.
|
| | |
|
| | |
|
| |
|
|
|
| |
I had thought that the sendme authentication things used for
onion services were 32-byte; they're still only 20.
|
| | |
|
| |
|
|
|
|
|
| |
This code deviates from current tor in that it allows missing
sendme authentications only when we know we're talking to an old
relay, or when we don't know the version of the relay we're talking
to.
|
| | |
|
| | |
|
| |
|
|
| |
This patch has a XXXXX kludge note in it.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
There's a problem, though: this code assumes that tags are 20 bytes
long whereas actually the tag type is part of the crypto layer info.
So maybe in the long term we need to move the queue of tags from the
send window into being part of the crypto layers.
|
| |
|
|
|
|
| |
This is incomplete because the cell crypto code doesn't actually
expose tags yet, and because it demands tags unconditionally,
without caring about the linkspec protocol version.
|
| | |
|
| |
|
|
|
| |
Parameterized for authenticated/unauthenticated operation, and
operation on circuits and streams.
|
| | |
|