Support Server params to Client and get Server full-version info #1955
+185
−10
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Version of iperf3 (or development branch, such as
masteror3.1-STABLE) to which this pull request applies:master
Issues fixed (if any): none specific
Brief description of code changes (suitable for use as a commit message):
Add support for sending server parameters to the client. This is done by the client informing the server that it supports getting its parameters, as part of sending the client's parameters (
"cap_server_params"). A server that support this feature will send to the client a new temporary stateSERVER_PARAM_EXCHANGE, followed by the servers parameters. After receiving the server parameters, the client set its state back to one before receivingSERVER_PARAM_EXCHANGE.I considered to send the client capabilities (instead of
"cap_server_params") and future server capabilities as a 32 bits map parameter"client_cababilities"and"client_cababilities", but I am not sure if bits map works o.k. between big/little endian platforms.The trigger for adding this feature is issue #1954 that asks for a server option to receive that the client output. If this PR will be merged it will be possible to suggest such enhancement.
To demonstrate the use this feature, the following two additional enhancements were added (may be split into separate PRs if needed):
"server_version") to the client. Client display the version in verbose mode (aslo add that the server display the client version in verbose mode). Note that as I see it, server version number is just for information, and not for deciding which feature is supported by the server. My approach is that future server capabilities will be added to the server parameters, and the client will be able to check which capabilities the server supports.-v, when requested by the client ("get_server_version"). Client is asking for the version info per new--get-server-versionoption, display the version info and terminates. If the option is not supported by the server, then the client notifies that.