m-lab / ndt-server / 447
82%
main: 82%

LAST BUILD BRANCH: sandbox-roberto-fix-close
DEFAULT BRANCH: main
Ran
Jobs 1
Files 19
Run time 7s
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: 58.844% (-0.2%) from 58.994%
447

push

travis-ci

web-flow 
spec: use int64, allow counter-flow messages (#71)

* Do not use float64 when int64 would suffice

It makes sense to use float64 where the measurement unit is
a floating, but using it when we're sending integer quantities
is actually a bit surprising.

While it's true that `float64` is native to the i386 platform
and `int64` it's not, I don't even know whether `int64` is slower
than `float64` and, even if that was the case, it would probably
be weird anyway to use `float64` rather than `int64`.

Another reason why I was using `float64` is that I didn't know
how to extact `int64`s from C code. But C code is gone in the
previous commit. Conclusion: let's use `int64` instead.

Now, why `int64` and not `uint64`? The different is subtle. We
know that in many cases golang is using signed integers also
for sizes, so that is not so surprising in golang. In Java there
is no unsigned, so in theory I could say I am doing this for
the sake of good old Java. The reality is that JSON cannot really
serialize numbers larger than 2^53 as integers, therefore the
distinction betwwn `int64` and `uint64` here is academic. Thus,
I have picked the most natural feat in golang.

(Should I check for overflow? In theory. In practice I think we
are good for quite some years without checking for overflow of
`int64` variables. Also, in the server side there are checks for
overflow of `int64`, but not of `int53`. In the client side I
think we should not care, since that is a minimal client.)

* spec: correctly mention the TLS overhead

Also, we don't have UDP overhead that we know of.

* spec: be pedantic and clarify the correct JSON integer bounds

As mentioned in the spec, this is quite an academic concern for
the moment and most likely in the future. However, clarify we have
thought about this issue, we currently consider it relevant for
pedantic implementations only, and recommend pedantic code to
make sure the int53 boundary is correctly... (continued)

692 of 1176 relevant lines covered (58.84%)

0.63 hits per line

Jobs
ID Job ID Ran Files Coverage
1 447.1 0
58.84
 Travis Job 447.1
Source Files on build 447
Detailed source file information is not available for this build.