| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit 04ab3cd848d7977baf58dd64ebfcad6aa54ecb17.
Reverted because we no longer need to "peek" into the opaque
`CircChanMsg` of a circuit reactor: now the implementation-dependent
part of the reactor is in charge of handling the channel messages,
and extracting `Relay` objects out of RELAY/RELAY_EARLY cells,
which then get processed in the base reactor.
|
| |
|
|
|
|
|
|
|
| |
This will be used in a future commit, inside the new generic circuit
reactor.
We need it because RELAY cells are handled very similarly, so we need
some way of finding out if a given generic chancell is actually a RELAY
cell that we can handle in an implementation-agnostic way.
|
| |
|
|
|
| |
This will be used in the stream reactor too (and the stream reactor will
eventually replace the corresponding client impl).
|
| |
|
|
| |
This is part of an implementation for proposal 368.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
This type wraps a futures::Sink, and allows it to be temporarily blocked
and unblocked.
I'm going to use this to implement padding-based circuit blocking,
according to the designs in !3225.
|
| |
|
|
|
|
| |
An async notification channel.
This uses `postage::watch::{Sender,Receiver}` internally.
|
| | |
|
| | |
|
| |
|
|
|
| |
This gets it as far as the outbound circuit->channel mpsc queue creation.
Also, we provide an accessor for it.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is where it belongs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NETINFO cells, which are sent in every handshake, may contain
timestamps. This patch adds an accessor for the timestamp in the
Netinfo messages, and teaches the tor-proto code how to compute the
minimum clock skew in the code.
The computation isn't terribly precise, but it doesn't need to be:
Tor should work fine if your clock is accurate to within a few
hours.
This patch also notes a Y2038 problem in the protocol: see
torspec#80.
Part of #405.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously coarsetime and the traffic-timestamp feature were
enabled, since they were only required for a small corner of the
guardmgr algorithm.
But in 1.0 and beyond we'll be adding a bunch of other features (eg,
netflow padding, DoS prevention) that will need coarsetime all over
the place.
And since we're going to be doing coarsetime all over the place, the
previous justification for making traffic-timestamping optional (the
tiny performance hit) is no longer relevant.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We need this for the circuit timeout estimator (#57). It needs to
know "how recently have we got some incoming traffic", so that it
can tell whether a circuit has truly timed out, or whether the
entire network is down.
I'm implementing this with coarsetime, since we need to update these
in response to every single incoming cell, and we need the timestamp
operation to be _fast_.
(This reinstates an earlier commit, f30b2280, which I reverted
because we didn't need it at the time.)
Closes #179.
|
|
|
This will cause some pain for now, but now is really the best time
to do this kind of thing.
|
