NDT-DEV email list created

[Sebastian Kostuch <>]

Hi
I'm very glad to announce that all changes related to adding JSON support to server and C, Java,
Flash clients have been successfully merged into trunk! From now on NDT server and clients will
exchange messages using old plain or new JSON format. Choosing which one to use is based on
MSG_EXTENDED_LOGIN message support of the client.

With such major change I would like to ask you if it would be appropriate to plan release new
version of NDT in nearest future (probably after JS UI will be completed which is our next goal to
achieve) ?

Regards,
Sebastian Kostuch

On 23.05.2014 09:10, Sebastian Kostuch wrote:

Hi
Recently I have added JSON support to Flash client. Changes are available on Issue147 branch.
Changes related to Java client are also ready for review (need just some small fixes, available
on Issue146 branch).
I will be very grateful for any feedback related to all these commits as it would be good to merge
them into trunk ASAP to unlock another tickets (especially the one with getting additional middle-box
test results).

Kind regards
Sebastian Kostuch

On 16.05.2014 10:09, Sebastian Kostuch wrote:

Hi
I have committed two more changesets regarding JSON format. First makes client try to reconnect
using old MSG_LOGIN message after receving error from server during login phase.
Second is about changing remaining messages to use JSON format.

Here you can find all commits regarding Issue145:
- r1052
- r1053
- r1055

Feel free to review code and all suggestions about what could be improved are welcome :).

Regards
Sebastian Kostuch

On 13.05.2014 22:11, Will Hawkins wrote:

Sebastian,

Thanks for doing all this great work. I will review your changes and
provide feedback as soon as possible!

Thanks again!
Will

On 05/13/2014 10:03 AM, Sebastian Kostuch wrote:

Hi again,
I have commited some changes on Issue145 branch where you can see my
first attempt to convert currently sent
messages as JSON ones. At this moment only tests specific methods have
been changed so there are still messages
that need converting what is my next goal. Meantime please feel free to
review current code and every feedback
will be very appreciated.

Please note that messages will be sent as JSON only if client sends
extended login message, otherwise it will still
use old format (C client is implemented to support it so you can test
changes and verify that it works how it should).

I have used Jansson library <http://www.digip.org/jansson/> for
encoding/decoding messages so it is required to install it on your
system in order
to compile program without errors.

Regards
Sebastian

On 23.04.2014 14:02, Sebastian Kostuch wrote:

Hi
according to last discussion about changing messages to JSON I have
created appropriated
ticket related to it. I would like to propose little more detailed
information about format of
such message.

I think that it would be good idea to change all possible messages to
use JSON (not
only the ones we expect will change in future).
While watching currently sent messages I have observed that they could be
divided into three sections:
1. Empty or containing only one value messages (such as the ones sent
along with finalize
message or these with port numbers/error values)
2. Messages formatted with pairs <variable name>: <variable value>
used mainly when
sending single Web100/10g variable
3. Messages containing more than one variables formatted as above or
containing only
number values separated by specific character

My idea is to format these messages using JSON as follows:
1. Empty message will contain empty object ("{}") and these with only
one value will look
like this: "{ msg : value }" and clients will obtain it using "msg"
key. This way it would be easy
to add another values to such message in future if necessary.
2. Something similar as to { msg : value } map but keys will be named
the same as
<variable name> and "value" will contain only actual variable's value.
3. Here I think it would be good idea to separate each variable value
and contain it
within JSON as separated key/value pair (simply divide it to look like
this presented in point 2).
With messages containing variables names it is easy but what about
when message looks like
this (in middlebox test it is used such way): value1;value2;value3 ?
Then we don't have variable's
names so it isn't obvious how to store such value in map (which key to
use?). So what about naming
such values with appropriated keys which will be documented in our
wiki? I dislike idea of formatting
such messages as they are currently as it would bring troubles in
future similar to the one I was
facing when trying to add next value to such string.

What do you think about such transition? Is it proper way to encode
our current messages within JSON
or do you see it another way? Looking forward to your feedback and
feel free to ask if anything isn't
clear :).

Regards
Sebastian