NDT-DEV email list created

[Aaron Brown <>]

Hey Sebastian,

I agree that it should work in a backwards compatible fashion if possible so if used on an old server, the client gracefully degrades. My general preference on the protocol changes would be to minimize changes in the short term, and look into something less constricting than the current protocol in the medium to long term.

Cheers,

Aaron

On Apr 4, 2014, at 6:35 AM, Sebastian Kostuch <> wrote:

Hi again
in addition to clients versioning I have mentioned in previous email I think that maybe it would be better to not determine
server actions based only on this information but rather using the one more detailed such as introducing versioning
of individual test protocols. I mean that server and client should have possibility to exchange information at the
beginning of each test which will contain version of protocol supported by both sites and such test will not be
performed if these versions differ significantly (which will mean that there were major protocol changes meantime
and much older clients can't be supported). Also this version information could be used by server to determine
what messages send to such client during specific test etc. What do you all think about such solution?

And when it comes to cooperation between new client and old server with Will's changes would it be possible to re-send
login message by new client when the extended one fails? Or is server closing socket when first message fails and it couldn't
be done?

Also I would like to thank you all for making this discussion so spirited :). I'm sure that with all ideas mentioned here we will
achieve our goal in the best way we can.

Regards
Sebastian Kostuch

On 04.04.2014 09:09, Sebastian Kostuch wrote:

Hi Will
shouldn't also compatibility between new client and old server be considered? Currently such client does not work and I'm getting
"Logging to server: Received wrong type of the message" error.
Also it probably would be good if we could number versions of our clients uniformly or maybe send additional information containing
type of client (ATM flash client is differently versioned when compared to c/java one)?

Regards,
Sebastian Kostuch

On 02.04.2014 15:43, 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 <
> 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