m-lab / ndt-cloud / 223
7%
master: 65%

LAST BUILD BRANCH: non-ws-with-json
DEFAULT BRANCH: master
Ran
Jobs 1
Files 1
Run time 0s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 65.532% (+0.6%) from 64.927%
223

push

travis-ci

bassosimone 
ndt7: allow padding inside of measurement messages

[I recommend to use `git show -w` to inspect this diff.]

This commit changes the specification to provide the server the
choice of using either binary or textual messages to generate
network load. The rationale of using binary messages is that it
is more efficient. The rationale of using textual messages is
that every message received by the client is a meaningful piece
of measurements that can be used to perform inferences.

Since measurement messages are too small to generate network
load, I've modified the specification to add random padding to
JSON messages. In this way, messages are large enough.

I have also modified the server to use textual messages and
padding. While in general I believe one MAY want to have a
server sending binary messages, after several tests in {3,4,5}G
networks, I've come to the conclusion that:

- either we further complicate the server implementation with
  more than a single goroutine for the sender, such that we
  collect (and store) measurements every N milliseconds

- or we use padding an every message is meaningful

The specific issue is that, with a slow 2G/3G network, the
sender is blocked in sending the binary messages and does
not have many chances of sampling BBR variables before the
client closes the connection because it's running for too
long (consider that a 10 second test runs for around two
minutes on my 2G network).

Therefore, one possible choice would have been to have a
goroutine for sampling BBR variables. But, still, even with
this sampling, the client would not receive many updates
and much information.

On the contrary, if each send() carries also a measurement,
the user experience is much more pleasant because one at
least sees a stream of measurements, albeit delayed by the
buffering queue in the operator's 2G machinery.

(IIRC @pboothe proposed this strategy to me when we first
discussed ndt7. I initially choose to go for binary messages
bec... (continued)

308 of 470 relevant lines covered (65.53%)

0.7 hits per line

Jobs
ID Job ID Ran Files Coverage
1 223.1 0
65.53
 Travis Job 223.1
Source Files on build 223
Detailed source file information is not available for this build.