NDT-DEV email list created

[Will Hawkins <>]

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