| Age | Commit message (Collapse) | Author |
|---|
|
Now there is functionality for conditionally supporting GetTCPInfo
depending on the platform. If the platform supports it, then the client
can call utilities.GetTCPInfo. In the case that the platform does not
support the GetTCPInfo function call, the result is an error of the type
`NotImplemented`.
|
|
This will only work on *nix systems. Code that displays information
in this PR is only exemplary -- I am sure that there are better
places in the code to display it!
|
|
Fixes #21
|
|
1. A misleading comment was corrected.
2. A typo was fixed.
|
|
Previously the code relied on the fact that the go runtime would wake up
the saturation go function at exactly 1 second intervals, as we asked.
With this change, the code takes into account any minor fluctuations in
that time when calculating the throughput in an interval. I hope that
this change is an improvement.
|
|
|
|
1. Create a separate package to handle the config information.
2. Move the saturate functionality into the rpm package.
3. Do general renaming/refactoring so that we are consistently
saying measurement and not RTT (this nomenclature is more consistent
with the standard).
|
|
Per a (to-be-released) update from the spec, the time for a DNS lookup
is no longer considered to make up a portion of the RPM.
|
|
Switch from calculating "difference" as percent difference to calculating
the difference as percent change.
|
|
As it turns out, I was misreading the algorithm for calculating the RPM
based upon the measurements taken during execution. This patch fixes
that mistake and also (starts) renames "RTT" as "measurement" (those are
technically a better nomenclature according to the spec.)
|
|
There was an error in prior versions when calculating the RPM in the
presence of reused connections because invalid time values were being
compared. This patch fixes that error.
|
|
Refactor RPM calculations to make them more reusble. Enable (perhaps
temporarily) probe calculations on the saturated connections. This
change is to check whether this makes our RPM calculations match the
ones generated by Apple's native client.
|
|
|
|
The first set of raw data and a tool for munging it into csv files. The
data look promising but there are a few things that we need to address.
|
|
When there is no debugging enabled, there was a null pointer dereference
as a result of invoking `saturate` with a null pointer to a `debug.Debugging`
structure.
|
|
This patch begins the work on updated RPM calculations using
the httptrace infrastructure. Because we are still not able
to break out the TLS handshake time due to upstream bugs, there
are some workarounds in place. However, the numbers appear much
more sane.
|
|
1. Make a traceable interface for all things that can be wrapped
in an httptrace.ClientTrace.
2. Refactor debugging system into debug package.
|
|
Two unrelated changes:
1. Add full support for self-signed HTTPS certificates on the server
2. Add support for multiple log levels: So far we only use one, but
adding support for additional levels will help us tier the levels to
filter out excessive messages.
|
|
|
|
See Issue #10.
Begin implementing the plumbing required to perform more precise RTT/RPM
measurements.
|
|
The newest version of the specification replaces the term
bearing with the term generating. This patch brings the updated
language to the code to make it easier to track the implementation's
conformance to the spec.
|
|
When running without SSL key logging enabled, the client
will segfault. This patch corrects that (obvious) error.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Add Dockerfile, minor tweaks to format of displayed stats
|
|
Pretty-print output (add banner, only display three sig-figs, etc)
|
|
|
|
|
|
|
|
Resolves Issue #6.
|
|
This fix might be controversial and we will have to confirm it with the
protocol designers: We will stop the actual download of the "large" file
when we are about to start doing the RPM calculation.
|
|
|
|
1. Add information about how to test against the Apple infrastructure
2. Add updated `-help` output (after -ssl-key-file support was added)
|
|
This is a "How was this ever working?" update.
1. As it turns out, when you customize a Transport for an
http.Client, the transport is 'naturally' an HTTP1 transport.
To make it connect via HTTP2, you must use an http2.Transport
from the golang.org/x/net/http2 package.
2. Add support for logging TLS per-session keys in order
to aid debugging.
|
|
|
|
|
|
|
|
|
|
|
|
By default go's network stack "helpfully" reuses the Transports
among http.Clients. This will artifically inhibit the full use
of the network. Creating new Transports for every http.Client
will keep this from happening.
|
|
|
|
Try intercepting a reader.
|
|
The previous method for reading the download was slow -- it
involved too many "context switches" out of library code where
the reading was actually happening. This method appears to be
better. We'll see.
|
|
|
|
The factor of five being included to account for the fact that a single
test accumulated five RTTs was being applied twice. This patch fixes
that.
|
|
In the case where the user omitted the -debug flag the client
would still output debugging information regardless. This commit
fixes that.
|
