NDT-DEV email list created

[Sebastian Kostuch <>]

Hi

On 04.04.2014 19:59, Will Hawkins wrote:
> Pre PS: There is a running version of the new server at
> ndt.iupui.mlab4.nuq0t.measurement-lab.org. Feel free to send connections
> to it to test the new MSG_EXTENDED_LOGIN semantics.
>
> On 04/04/2014 06: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?
> I think that is a great idea! It is one that I thought we would pursue
> at the start. However, it does not seem like the current test protocols
> allow for such an easy extension. At best, the test protocol seem to
> exchange port numbers. There is some extended handshaking with the MID
> test and the SWF test. But, that does not seem to provide enough "room"
> for us to work.
>
> Aaron, do you agree with that?
>
> > 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?
> I *think* that I answered this in my previous email. The problem with
> making a backward compatible client is exactly as you say: The server
> will immediately close the control connection when it receives a bad
> protocol message. So, the burden will fall almost entirely on the client
> to be compatible with old servers. :-(

I see, so it indeed is problem. What about making additional test running
before all the others (I think ATM there is possibility to determine tests'
order?) which goal will be to exchange client/server versions. If client
wouldn't request such test then server will know that client does not
support new protocol changes. However if such test will be requested
and performed then we can make server and client to exchange additional
information at the beginning of each next tests such as mentioned protocol
versions.
In such solution there shouldn't be problem with having old server and new
client as new client will just send request for performing this 
additional test
and old server which does not support it will just send response with 
test suite
not containing this new test (then client will abandon sending 
additional info
containing protocol versions and will assume that server supports only the
oldest one). What do you think about such method?
Also looking forward for Aaron's confirmation about thoughts mentioned 
above.
> > 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.
> I love working on this! Thank you both so much for your efforts!
>
> Will
>
> > 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 
> > > > > > <
> > > > > > <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