NDT-DEV email list created

[Aaron Brown <>]

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
>>