Skip to content

Forward compatibility #46

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Tracked by #30
i-n-g-o opened this issue Nov 15, 2024 · 1 comment
Closed
Tracked by #30

Forward compatibility #46

i-n-g-o opened this issue Nov 15, 2024 · 1 comment

Comments

@i-n-g-o
Copy link
Member

i-n-g-o commented Nov 15, 2024

How can a parser skip unknown options - by encoding the option-type in the option-id or by introducing a option-type id as a separate byte

@i-n-g-o i-n-g-o mentioned this issue Nov 15, 2024
25 tasks
@i-n-g-o
Copy link
Member Author

i-n-g-o commented Nov 15, 2024

An autoskip features does not solve version missmatches, it seems better to define version boundaries in the following manner:

  • 1. Introduce a "Since" column for options to track version
  • 2. Introduce a compatibility field in info-data.
    Set in server: This informs the client which rcp-version is actually in use by the application (vs. the rcp-version the rcp-server supports). The compatibility rcp version is derived from the entry in the "since version"-column of the options in use.
    Set in client: this informs the server about the clients backwards compatibility and can only be major versions. This is the case because adding options only increases the minor version. Major version changes indicate a breaking change in the protocol (e.g.: changing an options datatype).
    Client and server can implement different code paths for different major versions to be backward compatible.
  • 3. This makes a mandatory handshake useful (rfc: considering mandatory version-handshake #25)

Version Handshake:

  1. client sends info
  2. server compatibility version needs to be between client version and client down-to version (inclusive)
  3. server sends info or error
  4. version mismatch && server is strict -> close connection
  5. (version ok || server not strict) - wait for init
  6. client receives info: if version missmatch ? decide to close connection or skip packages if a parsing error occurs due to unknown options
  7. client sends initialize

@i-n-g-o i-n-g-o closed this as completed Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant