Skip to content
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

Somehow exchange versions in a way that won't add too much overhead and won't break #2

Open
jD91mZM2 opened this issue Dec 19, 2017 · 5 comments

Comments

@jD91mZM2
Copy link
Contributor

jD91mZM2 commented Dec 19, 2017

Currently an incompatible client will work until it doesn't. Then it will start behaving weirdly and nobody will know why.

Would it be better if errors could be detected earlier on?

Pros:

  • It's clear when clients are compatible and when they are not.
  • Perhaps there could be a compatibility mode for newer clients and older servers. That wouldn't be possible unless it actually knows if it's compatible.

Cons:

  • Clients that don't make use of whatever change there was would still break.
  • If there would be an exploit in synac and the server is running an old version, an attacker would know about it. (although synac is written in Rust, so I doubt there will be one 😎)
@Mnpn
Copy link

Mnpn commented Dec 19, 2017

Yes, exchange versions. Maybe make some versions backwards compatible but only as far as possible? E.g. client sends 0.2.4 and server is running 1.3.7, no problem, but e.g. client sends 0.1.0 and server is 1.8.4 (where the client doesn't even have support for roles) it would deny the connection?

That'll probably be slow, hard and messy but it's just an idea.

@jD91mZM2
Copy link
Contributor Author

jD91mZM2 commented Dec 19, 2017

That's the entire point of semver. <major>.<minor>.<patch>. I don't increase major if they're not compatible.

@jD91mZM2
Copy link
Contributor Author

I just thought of an issue: What if somebody makes their own server side application? We can't force them to use the same version numbers as us?
Solution: We make a protocol version number instead of using the application version.

@jD91mZM2
Copy link
Contributor Author

Another issue: How should the version even be exchanged? The protocol might change completely which means it breaks the version exchange... And unless we put it in the LoginSuccess packet we'd need to make a whole new packet for the version stuff, which would be annoying.

@jD91mZM2 jD91mZM2 changed the title Exchange versions Somehow exchange versions in a way that won't add too much overhead and won't break Dec 21, 2017
@jD91mZM2
Copy link
Contributor Author

BUMP

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

2 participants