Hi
as wrote yesterday, I have merged MultiplePorts branch into master.
This version is stable and I've ensured that
it does not break basic functionality.
Regards
Sebastian
On 25.06.2015 14:46, Sebastian Kostuch
wrote:
Hi Aaron,
I haven't look in detail on Peter's changes yet but after a brief
look the major critical
conflicts will be probably related to connection handling in S2C
and C2S tests. When it comes
to changes in web100srv file then the one on MultiplePorts are
rather small and don't touch
critical pieces of code. MultiplePorts branch has been added some
months ago and there were
few merges being done from master meanwhile (which also provided
many conflicts due to major changes in master code) so I think it
would be good to first merge these changes and then if needed
I could help with resolving conflicts with Peter's changes (they
also require some deep review while
ours are ready to merge as they are).
Protocol changes work ok with or without json usage, actually
there are
small changes to protocol at this moment as all major features
which were discussed in another
thread are planned to be implemented later as merging our branch
does not require them to be
ready for now (I've just added 2 new tests as separated ones and
when it comes to protocol they
differ from basic throughput tests with additional parameters
being sent by server at the beginning
of test, which are also contained in json 'msg' value).
Regards
Sebastian
On 25.06.2015 14:22, Aaron Brown
wrote:
Hey Sevastian,
I'm preparing to move to Virginia so haven't been able to
look at the various requests. I'm presuming this work and the
work Peter has been doing are incompatible. Is that accurate?
If so, is there a plan to get them to work together so they
can both be merged? Also, are the protocol changes you've
proposed compatible with the json protocol and what do they
look like?
Cheers,
Aaron
On Thursday, June 25, 2015, Sebastian Kostuch <>
wrote:
Hi,
I've added additional test run where server is run with
extended test options and client requests those tests.
I've also tested MultiplePorts changes when using old
client/server with our new one to ensure that nothing
will break when connecting old client with new server and
new client with old server. It seems like everything
is working ok and there should be no issues with using
these versions so if there won't be any feedback blocking
from merging these changes into master I will do so
tomorrow.
Regards
Sebastian
On 24.06.2015 18:14, Peter Boothe wrote:
A unit-testing framework was introduced
to NDT a little while back. It can be seen in action
in all the files named *_unit_tests.c, and the complete
source code of the unit testing framework can be found
in unit_testing.c
and unit_testing.h.
It's compatible with Automake and Autoconf, which
actually have built-in support for unit testing.
This means that we can now type "make check", and
pieces of the code will be unit-tested and
end-to-end tested. Not all the code is tested, but
hopefully over time an increasing percentage of the
code will be. This way we can make sure, as part of
the build process, that old bugs haven't reappeared
and that new features work as advertised.
I recognize that the MultiplePorts features
were not built with unit-testing in mind, so
instead of trying to shim unit-testing onto its
component parts (which looks like it would be a
big pain), can we add some end-to-end tests of the
new functionality (and keep the unit tests of the
old functionality) in web100srv_unit_tests.c? That
way we can be sure that these changes (a) do
actually work and (b) don't break old clients, and
we can encode those guarantees in code to make
sure they stay true. It shouldn't require too
much new work to do - I think the code would be an
almost line-for-line copy of the test_e2e() function,
but with a different command line for starting the
NDT client.
-Peter
|
