| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Our documentation had dated to an older version of our RPC stream
code, where all streams were automatically optimistic.
But as explained, our use of "optimistic"ness in RPC stream code is
now purely internal, to make it possible to get an DataStreamCtrl.
This isn't user-visible in our rpc_conn_open_stream code.
Closes #1583
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In brief: we _do_ correct implement correct optimistic vs
nonoptimistic behavior for RPC streams. Only our documentation was
wrong. Subsequent commits will fix our documentation more.
See #1583.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
tor-proto: Tweak StreamCtrl APIs for RPC.
See merge request tpo/core/arti!2755
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This method is experimental, so no semver note is needed.
It is redundant with `client_stream_ctrl()?.circuit()?`.
(The name and the unconditional return type of this method
are probably an error.)
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Since these return a client-specific type,
they need a client-specific name before we can stabilize them for RPC.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Semantically, the new name matches the behavior much better.
(A stream could well count as open if we had sent a RESOLVE but not
received a RESOLVED, so we might someday want to have an `is_open`
defined for _all_ streams, not just data streams.)
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The API for this type, and the fact that it implements
ClientStreamCtrl unconditionally, means that it is only for client
DataStreams.
|
| | | |/
| |/| |
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
tor-proto: Rewrite circuit reactor run_once() loop to use select!.
See merge request tpo/core/arti!2747
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
It's unclear to me why this warning didn't fire before! The the circuit
reactor had this exact same `debug_assert` prior to the refactoring,
taking a mutable reference to the `StreamMap`.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This is now handled in `Reactor::ready_streams_iterator()`.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is replaced by the new `Reactor::run_once()` impl.
Note: this removal is in a separate commit to make the diff of the
refactoring commits easier to review (the diff between the old and the
new impl is not meaningful because the new impl is practically a
rewrite).
|
| | | |
| | |
| | |
| | | |
This is replaced by `Option<RunOnceCmdInner>`.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This rewrites the circuit reactor main loop to use `select_biased!` to poll
multiple futures simultaneously.
The new `run_once()`, like the old, first waits for an initial
`CtrlMsg::Create`. Then, it uses a `select_biased!` to poll the
`chan_sender` sink and shutdown channel for readiness.
When the channel sink is ready, we poll the `control` and `input`
channels like before, as well as the new `ready_streams` `Stream`
(`ready_streams` is a `futures::Stream` that replaces the previous
`send_outbound()` function).
Most of the implementation remains unchanged, except the `handle_input`,
`handle_cell` and `handle_control` functions no longer send anything on
the `chan_sender` channel. Instead, they may do some (synchronous)
processing, and send instructions for the remaining work that needs to
be done (for example, for writing the cell to the `chan_sender`
channel). These instructions are handled at the end of `run_once()`,
and are encoded in the `RunOnceCmdInner` enum.
What this change does **not** do:
* the control channel *still* bypasses congestion control. We could
fix this by making the various reactor functions send the
`RunOnceCmdInner` commands to `run_once()` via a channel
(instead of returning them). This would enable the reactor to stop
reading the commands (except for handle `Sendme`, which would be
handled separately) if it's blocked on congestion control.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
No functional changes, just code motion.
|
| | | |
| | |
| | |
| | |
| | | |
We are about to use this in the circuit reactor (instead of
`pollish_send_unbounded`).
|
| | |/
|/| |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Improve and write a bunch of RPC documentation
Closes #1520, #1527, and #1296
See merge request tpo/core/arti!2748
|
| | | | |
|
| | |/ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
This type explains where every error came from, and explains why
each declined connect point was declined.
|
| | | |
|
| |/
|
|
| |
Subsequent commits will pipe this information forward to our errors.
|
| | |
|
| |
|
|
| |
(This TODO dates back to the point before we had sessions.)
|
| | |
|
| |
|
|
|
| |
Nothing uses it; its role in negotiation has been replaced
by the connect-point design.
|
| |
|
|
| |
Other parts of the crate no longer look at the .0 field directly.
|
| |\
| |
| |
| |
| | |
rpc: Move support for weak references behind an experimental feature
See merge request tpo/core/arti!2742
|
| | |
| |
| |
| |
| | |
We haven't decided how these should work (see #868), so having them
present by default is a bad idea.
|
| |\ \
| | |
| | |
| | |
| | | |
tor-rpc-connect: Address remaining "TODO RPC" notes.
See merge request tpo/core/arti!2743
|
| | | |
| | |
| | |
| | |
| | | |
Since it makes an exception, we need to be clear about the
exceptions that it _doesn't_ make.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
Since "obeying the constraints of a FileAccess" is a term of art,
this commit introduces links from the places where it is used
to the place where it is defined.
|
| | | |
| | |
| | |
| | | |
I have checked the relevant code, and it seems okay.
|
| | | | |
|
| | | | |
|
