You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we're using apiversion.APIVersion as our version type for the VPN RPC code. This code was originally written for client=>server version negotiation where only the server would support multiple versions, and the client would only send it's best version. In the VPN RPC protocol though, we would conceivably have situations where either side could be newer and so both sides should be able to negotiate the best version.
Proposal
Change our codervpn header/handshake format from codervpn <version> <role_enum> to codervpn <role_enum> <versions...>.
The sent versions in the header would be each major version and the maximum supported minor version on that major version. E.g. codervpn manager 1.3 2.2 3.0 means: 1.0, 1.1, 1.2, 1.3, 2.0, 2.1, 2.2, 3.0 are supported by this peer.
Once each end of the connection receives it's peer's handshake, it will compare the versions against each other to determine the highest mutual version. E.g. with codervpn peer1 1.3 2.2 3.0 and codervpn peer2 1.3 2.1 the version used will be 2.1. If the peers decide that no version is shared, they should log/notify the user and close the connection.
We will most likely need a new type to store these API versions and compare them. Maybe it should go in the apiversion package but we rename the old type and give this type a different name.
The validation method should have a signature like so, returning the best major/minor combination or an error if the two peers are not compatible.
func (v Version) NegotiateVersion(peer Version) (int major, int minor, err error) {}
The text was updated successfully, but these errors were encountered:
Changes the RPC header format from `codervpn <version> <role>` to
`codervpn <role> <version1,version2,...>`.
The versions list is a list of the maximum supported minor version for
each major version, sorted by major versions.
E.g. `1.0,2.3,3.1` means `1.0, 2.0, 2.1, 2.2, 2.3, 3.0, 3.1` are
supported.
When we eventually support multiple versions, the peer's version list
will be compared against the current supported versions list to
determine the maximum major and minor version supported by both peers.
Closes#15601
Currently we're using
apiversion.APIVersion
as our version type for the VPN RPC code. This code was originally written for client=>server version negotiation where only the server would support multiple versions, and the client would only send it's best version. In the VPN RPC protocol though, we would conceivably have situations where either side could be newer and so both sides should be able to negotiate the best version.Proposal
Change our
codervpn
header/handshake format fromcodervpn <version> <role_enum>
tocodervpn <role_enum> <versions...>
.The sent versions in the header would be each major version and the maximum supported minor version on that major version. E.g.
codervpn manager 1.3 2.2 3.0
means:1.0, 1.1, 1.2, 1.3, 2.0, 2.1, 2.2, 3.0
are supported by this peer.Once each end of the connection receives it's peer's handshake, it will compare the versions against each other to determine the highest mutual version. E.g. with
codervpn peer1 1.3 2.2 3.0
andcodervpn peer2 1.3 2.1
the version used will be2.1
. If the peers decide that no version is shared, they should log/notify the user and close the connection.We will most likely need a new type to store these API versions and compare them. Maybe it should go in the
apiversion
package but we rename the old type and give this type a different name.The validation method should have a signature like so, returning the best major/minor combination or an error if the two peers are not compatible.
The text was updated successfully, but these errors were encountered: