Skip to Content.
Sympa Menu

ndt-dev - Re: [ndt-dev] Allowing protocol changes without losing backward compatibility

Subject: NDT-DEV email list created

List archive

Re: [ndt-dev] Allowing protocol changes without losing backward compatibility

Chronological Thread 
  • From: Will Hawkins <>
  • To:
  • Subject: Re: [ndt-dev] Allowing protocol changes without losing backward compatibility
  • Date: Wed, 02 Apr 2014 19:07:49 -0400

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.


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

Archive powered by MHonArc 2.6.16.

Top of Page