NDT-DEV email list created

[Will Hawkins <>]

Sebastian,

This is really great work! I am so excited. :-)

Here at OTI/M-Lab, we've come up with a http-based download method for
the server-to-client test that we'd like to incorporate (which was why
we were so pleased to have the MSG_EXTENDED_LOGIN to tell the server
about the client). It is based on some changes to the server and the
client. We think that this is going to resolve some of the performance
issues that we've seen with reading from sockets in the Flash environment.

I am going to be working on this in Issue 144
(https://code.google.com/p/ndt/issues/detail?id=144).

This code has been relatively well-tested already, but we'd really like
to get this on M-Lab as quickly as possible so that we can have a) the
Flash client available so that it's easier for people to run tests and
b) those tests are accurate! I think it might make sense to push a
release when this follow-up to your work is complete?

Does all this seem reasonable?

Thanks again for all the awesome JSON work!

Will

On 05/28/2014 07:30 AM, Sebastian Kostuch wrote:
> 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 <https://code.google.com/p/ndt/source/detail?r=1052>
>>> - r1053 <https://code.google.com/p/ndt/source/detail?r=1053>
>>> - r1055 <https://code.google.com/p/ndt/source/detail?r=1055>
>>>
>>> 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
>>>>>>
>>>
>>
>