On 16 November 2017 17:15:36 CET, Pete Heist <notifications@github.com> wrote:
>
>> On Nov 16, 2017, at 3:47 PM, Toke Høiland-Jørgensen
><notifications@github.com> wrote:
>> Right, so partially implemented the selection logic in 343f60d
><https://github.com/tohojo/flent/commit/343f60da7be78d6fba13af02b60f37cdda9c4d24>.
>Still a few more things needed before it can be activated, so I have
>not enabled it in any tests yet. One of those things is the server-side
>check for irtt, another is internal to Flent...
>>
>
>After my afternoon walk, I’m re-thinking how to handle the server
>check. What I propose instead of adding a separate command is:
>
>* add a -n parameter to the client command, which will skip the running
>of the test. A single packet will be sent with both the open and close
>flags set, the server will evaluate the test parameters, as usual, and
>return a response with any parameter restrictions, as usual.
>
>* add a -hwait parameter, or similar, which allows specifying the list
>of durations to wait for the handshake response, that can be specified
>with or without -n
>
>Advantages:
>
>* you can use -strictparams if you want, to make sure the parameters
>you use for the test won't be restricted by the server
>
>* the specification of other parameters relevant to connecting
>(handshake wait times, hmac key, -4, -6, etc) is all done in an
>equivalent way
>
>* when it comes to protecting the server (which still needs work), I
>don’t have to deal with a new type of packet to rate limit
>
>Is this ok?
Yup, sounds like an excellent plan! :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.