NDT-DEV email list created

[Peter Boothe <>]

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