refactor: start pivoting netx (#396)
What do I mean by pivoting? Netx is currently organized by row:
```
| dialer | quicdialer | resolver | ...
saving | | | | ...
errorwrapping | | | | ...
logging | | | | ...
mocking/sys | | | | ...
```
Every row needs to implement saving, errorwrapping, logging, mocking (or
adapting to the system or to some underlying library).
This causes cross package dependencies and, in turn, complexity. For
example, we need the `trace` package for supporting saving.
And `dialer`, `quickdialer`, et al. need to depend on such a package.
The same goes for errorwrapping.
This arrangement further complicates testing. For example, I am
currently working on https://github.com/ooni/probe/issues/1505 and
I realize it need to repeat integration tests in multiple places.
Let's say instead we pivot the above matrix as follows:
```
| saving | errorwrapping | logging | ...
dialer | | | | ...
quicdialer | | | | ...
logging | | | | ...
mocking/sys | | | | ...
...
```
In this way, now every row contains everything related to a specific
action to perform. We can now share code without relying on extra
support packages. What's more, we can write tests and, judding from
the way in which things are made, it seems we only need integration
testing in `errorwrapping` because it's where data quality matters
whereas, in all other cases, unit testing is fine.
I am going, therefore, to proceed with these changes and "pivot"
`netx`. Hopefully, it won't be too painful.
2021-06-23 15:53:12 +02:00
|
|
|
// Package netxlite contains network extensions.
|
|
|
|
//
|
|
|
|
// This package is the basic networking building block that you
|
|
|
|
// should be using every time you need networking.
|
|
|
|
//
|
|
|
|
// Naming and history
|
|
|
|
//
|
|
|
|
// Previous versions of this package were called netx. Compared to such
|
|
|
|
// versions this package is lightweight because it does not contain code
|
|
|
|
// to perform the measurements, hence its name.
|
|
|
|
//
|
|
|
|
// Design
|
|
|
|
//
|
|
|
|
// We want to potentially be able to observe each low-level operation
|
|
|
|
// separately, even though this is not done by this package. This is
|
|
|
|
// the use case where we are performing measurements.
|
|
|
|
//
|
|
|
|
// We also want to be able to use this package in a more casual way
|
|
|
|
// without having to compose each operation separately. This, instead, is
|
|
|
|
// the use case where we're communicating with the OONI backend.
|
|
|
|
//
|
|
|
|
// We want to optionally provide detailed logging of every operation,
|
|
|
|
// thus users can use `-v` to obtain OONI logs.
|
|
|
|
//
|
|
|
|
// We also want to mock any underlying dependency for testing.
|
|
|
|
//
|
2021-09-08 22:48:10 +02:00
|
|
|
// We also want to map errors to OONI failures, which are described by
|
|
|
|
// https://github.com/ooni/spec/blob/master/data-formats/df-007-errors.md.
|
|
|
|
//
|
refactor: start pivoting netx (#396)
What do I mean by pivoting? Netx is currently organized by row:
```
| dialer | quicdialer | resolver | ...
saving | | | | ...
errorwrapping | | | | ...
logging | | | | ...
mocking/sys | | | | ...
```
Every row needs to implement saving, errorwrapping, logging, mocking (or
adapting to the system or to some underlying library).
This causes cross package dependencies and, in turn, complexity. For
example, we need the `trace` package for supporting saving.
And `dialer`, `quickdialer`, et al. need to depend on such a package.
The same goes for errorwrapping.
This arrangement further complicates testing. For example, I am
currently working on https://github.com/ooni/probe/issues/1505 and
I realize it need to repeat integration tests in multiple places.
Let's say instead we pivot the above matrix as follows:
```
| saving | errorwrapping | logging | ...
dialer | | | | ...
quicdialer | | | | ...
logging | | | | ...
mocking/sys | | | | ...
...
```
In this way, now every row contains everything related to a specific
action to perform. We can now share code without relying on extra
support packages. What's more, we can write tests and, judding from
the way in which things are made, it seems we only need integration
testing in `errorwrapping` because it's where data quality matters
whereas, in all other cases, unit testing is fine.
I am going, therefore, to proceed with these changes and "pivot"
`netx`. Hopefully, it won't be too painful.
2021-06-23 15:53:12 +02:00
|
|
|
// Operations
|
|
|
|
//
|
|
|
|
// This package implements the following operations:
|
|
|
|
//
|
|
|
|
// 1. establishing a TCP connection;
|
|
|
|
//
|
|
|
|
// 2. performing a domain name resolution;
|
|
|
|
//
|
|
|
|
// 3. performing the TLS handshake;
|
|
|
|
//
|
|
|
|
// 4. performing the QUIC handshake;
|
|
|
|
//
|
|
|
|
// 5. dialing with TCP, TLS, and QUIC (where in this context dialing
|
|
|
|
// means combining domain name resolution and "connecting");
|
|
|
|
//
|
|
|
|
// 6. performing HTTP, HTTP2, and HTTP3 round trips.
|
|
|
|
//
|
|
|
|
// Operations 1, 2, 3, and 4 are used when we perform measurements,
|
|
|
|
// while 5 and 6 are mostly used when speaking with our backend.
|
|
|
|
package netxlite
|