As we get more and more agent protocol implementations, the clients are being made to iterate through the various protocols to try and discover the protocol that works.

This causes unnecessary load on the Jenkins master as the master has to accept each incoming socket connection and then reject it with the unsupported protocol.

For example, if a Jenkins master is not in the A/B test of JNLPProtocol3 then every JNLP client using the latest remoting.jar will use two attempts to connect to the master and the master logs will be full of rejected connection logs which may distract the admin.

Much better is for the agent discovery by the client to be able to determine which protocols are supported and then in that way the list of protocols for the client to try can be filtered. If the client sees that the server does not support any of the protocols that the client knows it can thereby give a helpful user error message.

Advertising this information should not be a security risk as anyone who can connect to the agent port can try any protocol they want... and if they cannot connect to the agent port... then the information is useless to them.

Finally by advertising the information we can ensure that the client does not attempt to connect using a plaintext protocol to a server that only supports encrypted protocols. This would ensure that the agent secret could not be intercepted by forcing a client to downgrade to a plaintext protocol as the Jenkins Admin could disable the plaintext protocols (I have a follow-up JIRA for a UI to do that)