-
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
doc: explain how to write ooni nettests #506
Closed
Closed
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
Plan B's branch name is "db"
Allows to cut the most significant bit of complexity which also happened to be buggy :^)
Simplifies processing with python
We need to do something different now: simpler TH and basically no need to explore too much
bassosimone
added a commit
that referenced
this pull request
Sep 29, 2021
This commit introduce a measurement library that consists of refactored code from earlier websteps experiments. I am not going to add tests for the time being, because this library is still a bit in flux, as we finalize websteps. I will soon though commit documentation explaining in detail how to use it, which currrently is at #506 and adds a new directory to internal/tutorial. The core idea of this measurement library is to allow two measurement modes: 1. tracing, which is what we're currently doing now, and the tutorial shows how we can rewrite the measurement part of web connectivity with measurex using less code. Under a tracing approach, we construct a normal http.Client that however has tracing configured, we gather events for resolve, connect, TLS handshake, QUIC handshake, HTTP round trip, etc. and then we try to make sense of what happened from the events stream; 2. step-by-step, which is what websteps does, and basically means that after each operation you immediately write into a Measurement structure its results and immediately draw the conclusions on what seems odd (which later may become an anomaly if we see what the test helper measured). This library is also such that it produces a data format compatible with the current OONI spec. This work is part of ooni/probe#1733.
bassosimone
added a commit
that referenced
this pull request
Sep 29, 2021
This diff adds the prototype websteps implementation that used to live at #506. The code is reasonably good already and it's pointing to a roaming test helper that I've properly configured. You can run websteps with: ``` ./miniooni -n websteps ``` This will go over the test list for your country. At this stage the mechanics of the experiment is set, but we still need to have a conversation on the following topics: 1. whether we're okay with reusing the data format used by other OONI experiments, or we would like to use a more compact data format (which may either be a more compact JSON or we can choose to always submit compressed measurements for websteps); 2. the extent to which we would like to keep the measurement as a collection of "the experiment saw this" and "the test helper saw that" and let the pipeline choose an overall score: this is clearly an option, but there is also the opposite option to build a summary of the measurement on the probe. Compared to the previous prototype of websteps, the main architectural change we have here is that we are following the point of view of the probe and the test helper is much more dumb. Basically, the probe will choose which redirection to follow and ask the test helper every time it discovers a new URL to measure it w/o redirections.
3 tasks
bassosimone
added a commit
that referenced
this pull request
Sep 30, 2021
This diff adds the prototype websteps implementation that used to live at #506. The code is reasonably good already and it's pointing to a roaming test helper that I've properly configured. You can run websteps with: ``` ./miniooni -n websteps ``` This will go over the test list for your country. At this stage the mechanics of the experiment is set, but we still need to have a conversation on the following topics: 1. whether we're okay with reusing the data format used by other OONI experiments, or we would like to use a more compact data format (which may either be a more compact JSON or we can choose to always submit compressed measurements for websteps); 2. the extent to which we would like to keep the measurement as a collection of "the experiment saw this" and "the test helper saw that" and let the pipeline choose an overall score: this is clearly an option, but there is also the opposite option to build a summary of the measurement on the probe. Compared to the previous prototype of websteps, the main architectural change we have here is that we are following the point of view of the probe and the test helper is much more dumb. Basically, the probe will choose which redirection to follow and ask the test helper every time it discovers a new URL to measure it w/o redirections. Reference issue: ooni/probe#1733
bassosimone
added a commit
that referenced
this pull request
Sep 30, 2021
This is experimental code that was part of the branch #506 and that I am not sure whether it could really be useful when running in prod, but may be useful for running some benchmarks of websteps vs webconnectivity.
3 tasks
Everything has been merged, except for #531, for which I am not sure. I suspect that code is mostly going to be useful to me when running benchmarks. Either way, this PR can now be closed, as it has been superseded by the PRs cited above, where I merged the work done here in easier-to-digest chunks. |
bassosimone
added a commit
that referenced
this pull request
Oct 4, 2021
3 tasks
bassosimone
added a commit
that referenced
this pull request
Oct 4, 2021
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this pull request
Mar 8, 2022
This diff has been extracted from ooni#506. In it, we introduce wrapping constructors for types and we update the docs. These new constructures are used by the code in ooni#506. In itself, this work is part of ooni/probe#1733.
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this pull request
Mar 8, 2022
I have recently seen a data race related our way of mutating the outgoing request to set the host header. Unfortunately, I've lost track of the race output, because I rebooted my Linux box before saving it. Though, after inspecting why and and where we're mutating outgoing requets, I've found that: 1. we add the host header when logging to have it logged, which is not a big deal since we already emit the URL rather than just the URL path when logging a request, and so we can safely zap this piece of code; 2. as a result, in measurements we may omit the host header but again this is pretty much obvious from the URL itself and so it should not be very important (nonetheless, avoid surprises and keep the existing behavior); 3. when the User-Agent header is not set, we default to a `miniooni/0.1.0-dev` user agent, which is probably not very useful anyway, so we can actually remove it. Part of ooni/probe#1733 (this diff has been extracted from ooni#506).
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this pull request
Mar 8, 2022
While there, make sure netxlite has 100% coverage. Part of ooni/probe#1733 and diff has been extracted from ooni#506.
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this pull request
Mar 8, 2022
Part of ooni/probe#1733 and diff has been extracted from ooni#506.
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this pull request
Mar 8, 2022
Part of ooni/probe#1733 and diff has been extracted from ooni#506.
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this pull request
Mar 8, 2022
This diff attempts to modify the errors reported by our custom resolver by matching more strings from the stdlib. Part of ooni/probe#1733 and diff has been extracted from ooni#506.
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this pull request
Mar 8, 2022
This new API call performs DNS lookups for HTTPS records. Part of ooni/probe#1733 and diff has been extracted from ooni#506.
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this pull request
Mar 8, 2022
The main tutorial will be the one at ooni#506, but it's useful to also document the primitives used by measurex. So, here's the companion tutorial, which explains how to use the features in netxlite to perform measurements. This work is part of ooni/ooni.org#361.
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this pull request
Mar 8, 2022
Part of ooni#506. In parallel with tutorials, we also need to make sure we have good documentation.
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this pull request
Mar 8, 2022
Should fix ooni#523 (comment). Work part of ooni#506.
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this pull request
Mar 8, 2022
This commit introduce a measurement library that consists of refactored code from earlier websteps experiments. I am not going to add tests for the time being, because this library is still a bit in flux, as we finalize websteps. I will soon though commit documentation explaining in detail how to use it, which currrently is at ooni#506 and adds a new directory to internal/tutorial. The core idea of this measurement library is to allow two measurement modes: 1. tracing, which is what we're currently doing now, and the tutorial shows how we can rewrite the measurement part of web connectivity with measurex using less code. Under a tracing approach, we construct a normal http.Client that however has tracing configured, we gather events for resolve, connect, TLS handshake, QUIC handshake, HTTP round trip, etc. and then we try to make sense of what happened from the events stream; 2. step-by-step, which is what websteps does, and basically means that after each operation you immediately write into a Measurement structure its results and immediately draw the conclusions on what seems odd (which later may become an anomaly if we see what the test helper measured). This library is also such that it produces a data format compatible with the current OONI spec. This work is part of ooni/probe#1733.
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this pull request
Mar 8, 2022
This diff adds the prototype websteps implementation that used to live at ooni#506. The code is reasonably good already and it's pointing to a roaming test helper that I've properly configured. You can run websteps with: ``` ./miniooni -n websteps ``` This will go over the test list for your country. At this stage the mechanics of the experiment is set, but we still need to have a conversation on the following topics: 1. whether we're okay with reusing the data format used by other OONI experiments, or we would like to use a more compact data format (which may either be a more compact JSON or we can choose to always submit compressed measurements for websteps); 2. the extent to which we would like to keep the measurement as a collection of "the experiment saw this" and "the test helper saw that" and let the pipeline choose an overall score: this is clearly an option, but there is also the opposite option to build a summary of the measurement on the probe. Compared to the previous prototype of websteps, the main architectural change we have here is that we are following the point of view of the probe and the test helper is much more dumb. Basically, the probe will choose which redirection to follow and ask the test helper every time it discovers a new URL to measure it w/o redirections. Reference issue: ooni/probe#1733
ainghazal
pushed a commit
to ainghazal/probe-cli
that referenced
this pull request
Mar 8, 2022
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.
Checklist
Location of the issue tracker: https://github.com/ooni/probe
Description
This is a rather advanced draft that still requires QA. I am going
to push this commit so others soon can start to review it.
This draft supersedes #505
This diff also contains a library of building blocks that is
instrumental to complete websteps. In fact, the tutorial I have
written here will eventually guide people to write their own
simplified implementation of websteps (and Web Connectivity).
I have not written any test for the new code so far. It is
also a stretch to call this new code. It is existing code that
has been written by me or @kelmenhorst that I have adapted
for the purpose of writing the tutorial.
The nice exercise of writing a tutorial is that you are more
easily frustrated if the code is difficult to use XD.
How to review the tutorials
Navigate to
internal/tutorial/measurex
and follow the linksinside the
README.md
file. Or go to https://github.com/ooni/probe-cli/tree/planc/internal/tutorial/measurexand read starting from there, which is equivalent.
Editing is quite tricky. Most text comes from comments in
Go files. You need to edit the comments and then you need
to regenerate all the files. The
README.md
of theinternal/tutorial/measurex
tutorial contains instructionson how to do that.
What remains to be done before merging
Mainly adding tests and making sure I didn't lose
anything when adapting existing code. I like the interface
of the new code more, but existing code written last
August may have a better implementation of corner cases.