-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor(dslx): unify TLS and QUIC handshake options #1378
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We want to use the DSL inside the oohelperd. We don't care about collecting observations in the oohelperd. So, the plan is that of abstracting the ConnPool, renaming it Runtime, and giving it the power to create abstract Traces. The oohelperd will use a MinimalRuntime (sketched out by this commit) that will not collect any observation. Measuring code, instead, will use a MeasurexRuntime that will collect observations. This commit is just the first step. We rename and introduce the MinimalRuntime. No significant functional changes so far.
This diff builds on the previous diff and uses an abstract trace inside of the dslx package. By using an abstract trace, we can choose between using: - a runtime that collects observations, based on measurexlite; and - a minimal runtime that does not collect observations. To make the trace abstract, we need to modify measurexlite's trace such that it can be used as an interface. In turn, this means we need to update the throttling package such that it uses an abstract trace definition. Strictly speaking, we could have avoided introducing this abstraction, but it seems better to also use an abstract trace there, as it allows for improving the decoupling with measurexlite.
Currently, we pass these fields to each DSL function. However, if we want to load the functions from JSON, which is something we have experimented with in the richer input context, we can't do this. These fields should instead belong to the runtime. A subsequent diff will modify the DSL functions to take them from the runtime.
This diff builds upon the previous diff to use the Runtime to get the logger, ID generator, and zero time. By doing this, we make most structures that DSL functions takes as input or emit in output serializable and deserializable.
Rather than using custom fields for testing, we can configure in the runtime a custom model.MeasuringNetwork. We're not doing this just to simplify the codebase, rather the underlying intent here is making sure we don't need to keep much state in each function, so we can refactor them to be pure functions wrapped by an adapter that produces the desired type. In turn, by doing that, we will be able to factor complexity around invoking functions and parsing their results. In turn, by doing that, we will be able to modify the signature of the functions and do the following: 1. allow the DSL model to include stages that take in input a Maybe value rather than a value, so we can observe failures more easily than we do now and we can write inline code to save into test keys; 2. allow the DSL model to much more easily be refactored to use channels, which in turn enables us to compose operations more naturally and increase the amount of overlapping (think, e.g., how this enables the possibility of waiting additional time for a DNS-over-UDP resolver to wait for late/duplicate replies).
This diff modifies dslx functions to always use the MeasuringNetwork for testing rather than using specific func fields. By doing this, we open up the possibility of simplifying the state of each func, with the ultimate goal of making them pure functions. By making them pure functions, we make the code more manageable and easy to modify, which opens up for additional refactorings.
Introduce an adapter type that converts a pure function into a Func and start using it whenever it's easy, rather than rolling out structs that implement the Func type when we actually don't have state. This change is an improvement because we're creating the necessary conditions from moving complexity out of the functions that actually do something, which should be simpler, and adapters, which should contain the same, equal logic for creating pipelines. The ultimate goal here is to be able to have stages that accept a Maybe[A] as input, to be able to add inline evaluators that set test keys. I want to reach this goal by making the necessary transformation at the adapters level rather than changing each of the Func prototype at once.
This diff reduces the state kept by the tlsHandshakeFunc struct so that we can apply a transformation similar to the one we applied for TCPConnect() and implement TLSHandshake() using a pure func. The overall objective is that of factoring away completixity to enable manipulating this code more easily. While there, let's note that the changes applied here mean that we can reuse this code for configuring tls.Config for the QUICHandshake.
This diff takes advantage of the fact that now the TLSHandshakeOption are independent of the tlsHandshakeFunc structure, so we can use the same options for configuring the QUIC handshake.
Conflicts: internal/dslx/dns.go internal/dslx/dns_test.go internal/dslx/quic.go internal/dslx/quic_test.go internal/dslx/tcp.go internal/dslx/tcp_test.go internal/dslx/tls.go internal/dslx/tls_test.go
bassosimone
commented
Oct 25, 2023
bassosimone
commented
Oct 25, 2023
bassosimone
changed the title
Issue/2545 small
refactor(dslx): unify TLS and QUIC handshake options
Oct 25, 2023
Murphy-OrangeMud
pushed a commit
to Murphy-OrangeMud/probe-cli
that referenced
this pull request
Feb 13, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes ooni/probe#2611.