| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
I think that the reason we added this was in case we needed
different behavior from DataStream; but on reflection it does seem
that we don't. Having a single type here will make things a bit
simpler.
|
| | |
|
| |
|
|
|
|
|
| |
The function never yields anything but an `Ok`, so we can
simplify its type.
(Not a stable feature, so no semver entry needed)
|
| |
|
|
|
| |
This requires yet more plumbing—this time, of HsCircPool and
NetDirProvider.
|
| |
|
|
|
|
|
|
|
| |
When we go to answer a RendRequest, we need to have a few objects
present. This commit makes sure that they're available at the
right places.
We also note a significant problem with the need for a Subcredential
here.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IntroPointId was RelayIds but that's wrong, because there can be
different IPTs at the same relay - but also because an established IPT
might change its RelayIds.
Use IptLocalId instead, which I think is the type we decided to use
for this, and which is, conveniently, Copy.
And change the variable names to match, everywhere.
Specifically: in places where an intro point is implied (ipt_mgr.rs,
ipt_establish.rs) use the name `lid` everywhere, like in ipt_mgr.rs.
Elsewhere, use `ipt_lid`.
(We could use a longer name, but in that case it should be changed in
ipt_mgr.rs too.)
No actual functional change in this commit.
|
| |
|
|
|
|
|
| |
We need a type that holds a rend_handshake::IntroRequest object
internally, but where we don't materialize that object from the
Introduce2 message inside the MsgHandler, since that's more crypto
than we want to put in that task.
|
| |
|
|
|
|
|
|
|
|
| |
At the very least, I need FatalError to be distinct:
IptEstablisher::new ought not to fail unless everything is terrible.
Add a the Spawn variant to FatalError (that we'll need soon) and the
Bug variant (which it seems likely we might need).
This also gets rid of the crate-level Result alias.
|
| |
|
|
|
|
| |
If the service encouters operational errors, surfacing them here is
not helpful. So these methods ought to work, if they weren't called
erroneously.
|
| |
|
|
|
|
|
|
|
|
| |
We want to change the error return types of many methods, so we need a
way to name `std::result::Result`.
We could use `StdResult`, but, actually, properly distinguishing the
kinds of errors that can occur in various contexts means we don't
actually want a single Error type for the whole crate, so
`crate::Result` is going to go away.
|
| | |
|
|
|
Also, removed some older structures that don't make sense in the
current design.
Closes #970
|