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: Aaron Brown <>
  • To: Will Hawkins <>
  • Cc: "" <>
  • Subject: Re: [ndt-dev] Allowing protocol changes without losing backward compatibility
  • Date: Wed, 2 Apr 2014 13:43:53 +0000
  • Accept-language: en-US

Fine by me


On Apr 2, 2014, at 1:05 AM, 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
>>> <>
>>> 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