NDT-DEV email list created

[Aaron Brown <>]

Hey Peter,

That looks reasonable to me. I’d been trying to avoid scheduling a test that the server couldn’t perform, but if the client immediately cancels, that’s probably not all that big of a deal.

Cheers,

Aaron

On May 8, 2015, at 5:36 PM, Peter Boothe <> wrote:

I think the right thing is for the server to respond with the tests and test parameters it accepted.  Then the client can decide whether that set of accepted parameters is okay or not.  This allows NDT to future-proof itself as more test parameters arrive (or depart).  So the test request message would be:

{

  “msg”: “v3.5.5”,

  “tests”: “54",

  “test_arguments”: {

      “2”: {     # TEST_C2S

          “duration”: 15,

          “streams”: 5

      },

      “4”: {     # TEST_S2C

          “duration”: 10,

          “streams”: 1

      },

      # requesting the TEST_STATUS test - no args == default args

      # requesting the TEST_META test - no args == default args

  }

}

and the response from an old server would be (in the second MSG_LOGIN message with the test ids):

{

   "msg": "2 4 16",

}

while the response from a new server (in the second MSG_LOGIN message with the test ids) would be:

{

   "msg": "2 4 16",

   "test_arguments": {
     "2": {

          “duration”: 15,

          “streams”: 5

      }

      "4": {

         “duration”: 10,

         “streams”: 1

      }

}

Then the client, if they don't like response, can just drop the connection.  Then old clients can contact new servers and vice-versa.

  -Peter

On Fri, May 8, 2015 at 3:39 PM, Aaron Brown <> wrote:

Hey Peter,

If a server can’t perform the requested test (e.g. it’s an old server, and can’t handle multiple streams), I want the client to be able to make a decision about what to do, and not be surprised when it suddenly gets a different set of tests than it requested. If those parameters aren’t critical to what the client wanted, it can retry without the parameters set, but there’s no sense in automatically performing a different test if it’s not doing what the client wanted to do.

Cheers,

Aaron

On May 8, 2015, at 3:32 PM, Peter Boothe <> wrote:

Isn't that what you want?  We want old clients to be able to make requests to new servers, and we want old servers to service requests from new clients.

Or do we not want old servers to service requests from new clients?

  -Peter

On Fri, May 8, 2015 at 11:41 AM, Aaron Brown <> wrote:

Hey Peter,

That had been my original thought, but I wanted to ensure that an older server would deny the tests if it didn’t support arguments. From looking through the code, it looks like it’d just blindly accept the test and ignore the arguments.

Cheers,

Aaron

On May 8, 2015, at 11:32 AM, Peter Boothe <> wrote:

I think that this idea is good in the generalities and wrong in the specifics.  In particular, the new format should be a superset of the old format.

{

  “msg”: “v3.5.5”,

  “tests”: “54",

  “test_arguments”: {

      “2”: {     # TEST_C2S

          “duration”: 15,

          “streams”: 5

      },

      “4”: {     # TEST_S2C

          “duration”: 10,

          “streams”: 1

      },

      # requesting the TEST_STATUS test - no args == default args

      # requesting the TEST_META test - no args == default args

  }

}

On Fri, May 8, 2015 at 9:51 AM, Aaron Brown <> wrote:

Hey Folks,

The current extended json login message is now just looks like this right:

{
   “msg”: “v3.5.5”,
   “tests”: “54"
}

There’s a MultiplePorts branch that is doing multiple streams, along with interval snapshots and some other features. Given that the new tests accept test parameters (e.g. “c2s duration”, “snapshot delay”, etc), my thought is to change the extended login message some:

{
  “msg”: “v3.5.5”,
  “requested_tests”: {
      “2”: {     # TEST_C2S
          “duration”: 15,
          “streams”: 5
      },
      “4”: {     # TEST_S2C
          “duration”: 10,
          “streams”: 1
      },
      “16”: {},   # requesting the TEST_STATUS test
      “32”: {},   # requesting the TEST_META test
  }
}

If a client requested an unknown test argument, then the server would deny the request. Assuming the client doesn’t care about the extended parameters, it could just send the old request style, or it could send the new request style with no requested options. Existing servers would simply deny the test since there’s no “test” option included.

What do folks think?

Cheers,
Aaron

--

Peter Boothe |  | ᴹ̶LAB | http://measurementlab.net

--

Peter Boothe |  | ᴹ̶LAB | http://measurementlab.net

--

Peter Boothe |  | ᴹ̶LAB | http://measurementlab.net