Skip to content

fix(ndt7-protocol.md): clarify test "runtime" concept #426

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.

Sign up for GitHub

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

Merged
bassosimone merged 4 commits into from
Feb 27, 2026
+13 −6
Merged

fix(ndt7-protocol.md): clarify test "runtime" concept #426

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
63d12f1
fix(ndt7-protocol.md): clarify test "runtime" concept
bassosimone Feb 27, 2026
a2acc3f
Update ndt7-protocol.md
bassosimone Feb 27, 2026
51482c7
Update ndt7-protocol.md
bassosimone Feb 27, 2026
58b098b
Update ndt7-protocol.md
bassosimone Feb 27, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 13 additions & 6 deletions spec/ndt7-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ protocol](https://github.com/ndt-project/ndt). Ndt7 is based on
WebSocket and TLS, and takes advantage of TCP BBR, where this
flavour of TCP is available.

This is version v0.10.0 of the ndt7 specification.
This is version v0.11.0 of the ndt7 specification.

## Design choices

Expand Down Expand Up @@ -55,8 +55,9 @@ clients should be maximally simple, and that all complexity should
implemented on the server side.

Ndt7 should consume few resources. The maximum runtime of a test should
be ten seconds, but the server should be able to determine if the performance
if performance has stabilized in less than ten seconds and end the test early.
be ten seconds since the WebSocket handshake completed. The server should
be able to determine if the performance has stabilized in less than
ten seconds and, if so, end the test early.

## Protocol description

Expand Down Expand Up @@ -122,6 +123,11 @@ Connection: Upgrade\r\n
\r\n
```

The client SHOULD set a reasonable timeout (e.g., 5-10 seconds) to
allow for the TCP connect, TLS handshake, and WebSocket handshake
to complete. The test proper starts _after_ the WebSocket handshake
has successfully completed.

### WebSocket channel usage

Once the WebSocket channel is established, the client and the server
Expand Down Expand Up @@ -157,9 +163,10 @@ MAY change the size of such messages to accommodate for fast clients, as
mentioned above. See the appendix for a possible algorithm to dynamically
change the message size.

The expected duration of a test is _up to_ ten seconds. If a test has
been running for at least thirteen seconds, an implementation MAY close the
underlying TLS connection. This is allowed to keep the overall duration
The expected duration of a test is _up to_ ten seconds. The zero time to
establish duration is the time when the WebSocket handshake completed. If
a test has been running for at least thirdteen seconds, an implementation MAY
close the underlying TLS connection. This is allowed to keep the overall duration
of each test within a thirteen second upper bound. Ideally this SHOULD
be implemented so that immediately after thirteen seconds have elapsed, the
underlying TLS connection is closed. This can be implemented, e.g., in C/C++
Expand Down
Loading