Skip to content

Simplify protocol detection with async/await#577

Merged
olix0r merged 3 commits intomainfrom
ver/detect-await
Jun 23, 2020
Merged

Simplify protocol detection with async/await#577
olix0r merged 3 commits intomainfrom
ver/detect-await

Conversation

@olix0r
Copy link
Member

@olix0r olix0r commented Jun 22, 2020

The protocol detection middleware is pretty verbose, including a manual
future implementation that manages a complex set of state types.

This can all be simplified with async/await (at the cost of ~2 boxes per connection).

olix0r added 2 commits June 21, 2020 21:36
The protocol detection middleware is pretty verbose, including a manual
future implementation that manages a complex set of state types.

This can all be simplified with async/await (at the cost of a `Box` per
connection).
There's no reason that the detect module needs to provide the actual
protocol detection implementation. This is better-respresented as an
async-trait.
@olix0r olix0r requested a review from a team June 22, 2020 17:27
Copy link
Contributor

@kleimkuhler kleimkuhler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good

@olix0r olix0r requested a review from hawkw June 23, 2020 18:36
Copy link
Contributor

@hawkw hawkw left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems good to me --- this doesn't change the SNI detection state machine, which is the part that i feel like probably deserves the most attention to be sure we don't introduce subtle behavior changes.

Comment on lines +61 to +62
// The `accept` is cloned into the response future, so its readiness isn't important.
Poll::Ready(Ok(()))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this does seem like a slight change in behavior, but i don't think it's one that actually matters. is there a reason we changed this? it seems like we could continue driving it here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it was technically a bug before. We would poll the accept to ready, and then clone it, and then not poll the clone to ready (which is technically required).

I think, practically, this stack doesn't use readiness and there's a oneshot inside of it.

@olix0r olix0r merged commit 7830d24 into main Jun 23, 2020
@olix0r olix0r deleted the ver/detect-await branch June 23, 2020 21:22
olix0r added a commit to linkerd/linkerd2 that referenced this pull request Jun 23, 2020
This release primarily features an upgrade of the proxy's underlying
Tokio runtime and its related libraries. We've observed lower latencies
in initial benchmarks, but further testing and burn-in is warranted.

Also, the proxy now honors the `LINKERD_PROXY_LOG_FORMAT=json`
configuration to enable JSON-formatted logging.

---

* Add a CODEOWNERS (linkerd/linkerd2-proxy#558)
* Fix shellcheck issues in shell scripts (linkerd/linkerd2-proxy#554)
* update the proxy to use std::future and Tokio 0.2 (linkerd/linkerd2-proxy#568)
* Prune unused dependencies (linkerd/linkerd2-proxy#569)
* Support LINKERD_PROXY_LOG_FORMAT=json (linkerd/linkerd2-proxy#500)
* Change docs references from "master" to "main" (linkerd/linkerd2-proxy#571)
* Upgrade tokio-rustls & webpki. (linkerd/linkerd2-proxy#570)
* Makefile: Add shellcheck recipe (linkerd/linkerd2-proxy#555)
* Update proxy-api dependencies (linkerd/linkerd2-proxy#573)
* integration: fix missing traces (linkerd/linkerd2-proxy#572)
* Update Rust to 1.44.0 (linkerd/linkerd2-proxy#574)
* Use async/await to simplify connection-accept task (linkerd/linkerd2-proxy#575)
* Update Rust to 1.44.1 (linkerd/linkerd2-proxy#576)
* outbound: Split HTTP endpoint builder (linkerd/linkerd2-proxy#578)
* Simplify protocol detection with async/await (linkerd/linkerd2-proxy#577)
* Pin proxy-api at v0.1.13 (linkerd/linkerd2-proxy#579)
olix0r added a commit to linkerd/linkerd2 that referenced this pull request Jun 24, 2020
This release primarily features an upgrade of the proxy's underlying
Tokio runtime and its related libraries. We've observed lower latencies
in initial benchmarks, but further testing and burn-in is warranted.

Also, the proxy now honors the `LINKERD_PROXY_LOG_FORMAT=json`
configuration to enable JSON-formatted logging.

---

* Add a CODEOWNERS (linkerd/linkerd2-proxy#558)
* Fix shellcheck issues in shell scripts (linkerd/linkerd2-proxy#554)
* update the proxy to use std::future and Tokio 0.2 (linkerd/linkerd2-proxy#568)
* Prune unused dependencies (linkerd/linkerd2-proxy#569)
* Support LINKERD_PROXY_LOG_FORMAT=json (linkerd/linkerd2-proxy#500)
* Change docs references from "master" to "main" (linkerd/linkerd2-proxy#571)
* Upgrade tokio-rustls & webpki. (linkerd/linkerd2-proxy#570)
* Makefile: Add shellcheck recipe (linkerd/linkerd2-proxy#555)
* Update proxy-api dependencies (linkerd/linkerd2-proxy#573)
* integration: fix missing traces (linkerd/linkerd2-proxy#572)
* Update Rust to 1.44.0 (linkerd/linkerd2-proxy#574)
* Use async/await to simplify connection-accept task (linkerd/linkerd2-proxy#575)
* Update Rust to 1.44.1 (linkerd/linkerd2-proxy#576)
* outbound: Split HTTP endpoint builder (linkerd/linkerd2-proxy#578)
* Simplify protocol detection with async/await (linkerd/linkerd2-proxy#577)
* Pin proxy-api at v0.1.13 (linkerd/linkerd2-proxy#579)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants