Simplify protocol detection with async/await#577
Conversation
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.
hawkw
left a comment
There was a problem hiding this comment.
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.
| // The `accept` is cloned into the response future, so its readiness isn't important. | ||
| Poll::Ready(Ok(())) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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)
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)
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).