NDT-DEV email list created

[Will Hawkins <>]

Feel free to take a look at r1045 and r1046. I've added support for
MSG_EXTENDED_LOGIN to the server and implemented support for sending the
client version in the Flash client.

I limited the possible version number length to 32 bytes. That is
hard-coded at this point, but I will change it to a constant once you
all think these are reasonable changes.

Will

On 04/02/2014 09:43 AM, Aaron Brown wrote:
> Fine by me
> 
> Cheers,
> Aaron
> 
> On Apr 2, 2014, at 1:05 AM, Will Hawkins 
> <>
>  wrote:
> 
>> Thank you for bringing up this discussion. I will need similar 
>> functionality in the very near future to support S2C tests in the Flash 
>> applet. I like the idea of an extended login message like:
>>
>> Type Length Value
>> 11   (>= 1) (first byte has MSG_LOGIN semantics) (subsequent bytes are 
>> client version number in US-ASCII, the way that the server's MSG_LOGIN is 
>> structured)
>>
>> If that is something that people would be okay with, I can take a whack at 
>> implementing it on the server side. The client version number could be 
>> incorporated into the TestOptions struct since it already gets passed to 
>> each of the test functions. The test functions can use that to guard 
>> non-default functionality.
>>
>> As I said, this type of message will really help me in the next few days 
>> as I try to improve the performance of the Flash client so I'm happy to 
>> work on it!
>>
>> Thanks again for bringing this matter up, Sebastian.
>>
>> Will
>>
>>
>> On 4/1/14, 9:11 AM, Aaron Brown wrote:
>>> It might be cleaner in the long run to introduce a new message type
>>> (MSG_EXTENDED_LOGIN or something). The client could try logging in with
>>> that extended login message, and if it fails, it could fall back to
>>> MSG_LOGIN if applicable. We could probably also move to a JSON structure
>>> as the message content in the process. If we think through that route,
>>> it might make it easier down the road to do something that works over
>>> HTTP as well.
>>>
>>> Cheers,
>>> Aaron
>>>
>>> On Mar 31, 2014, at 8:56 AM, Sebastian Kostuch 
>>> <
>>> <mailto:>>
>>>  wrote:
>>>
>>>> Hi,
>>>> while working on Issue136
>>>> <https://code.google.com/p/ndt/issues/detail?id=136&colspec=ID%20Type%20Status%20Severity%20Milestone%20Priority%20Owner%20Summary>
>>>> I have encountered some difficulties with making little changes in
>>>> middlebox protocol
>>>> without making old client not working with new server. So after some
>>>> investigation I would like to propose
>>>> following changes in order to solve this problem:
>>>>
>>>> To make protocol changes possible in future versions without losing
>>>> backward compatibility both server and client
>>>> need to know versions of each other. At this moment server has no
>>>> information about client one. To fix this we
>>>> need our clients to sent such information before tests are being run
>>>> but we can't either change currently sent messages
>>>> (such as the login message which could contain client version) either
>>>> pass some new type of message from client to
>>>> server (old server would know nothing about it).
>>>>
>>>> So probably it would be good to create some new test running before
>>>> any other for only this versions exchange.
>>>> This test should be obligatory (when server will not receive id of
>>>> this one in client's request then it will treat client as the
>>>> one with older versions, before proposed changes). On the other  hand
>>>> when new client will send such test request to
>>>> old server, then it would be just ignored (marked as not supported)
>>>> and all will work ok also. This way backward
>>>> compatibility should be assured.
>>>>
>>>> Having both server and client know about their versions we can then
>>>> perform some changes in tests protocol. And
>>>> here goes the solution for Issue136: instead of always sending
>>>> additional RTT and TCP buffer size values server will
>>>> just check which client he is connected to. If it is older one which
>>>> does not support newest middlebox test protocol then
>>>> these values will not be attached to final results.
>>>>
>>>> Also instead of checking only client/server version we could introduce
>>>> numbering of individual tests protocols and server
>>>> would sent such information to client before tests (i.e. string
>>>> containing entries such as "[testID]-[protocolVersion]").
>>>>
>>>> What do you think about such solution? Is this good way to assure
>>>> backward compatibility and making introducing
>>>> some protocol changes in future easier? Also if you have any questions
>>>> feel free to ask them :).
>>>>
>>>> Regards,
>>>> Sebastian Kostuch
>>>
>