+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: Proposal: Allowed Protocols configuration (/thread-2730.html)
Proposal: Allowed Protocols configuration - LogicParrot - 01-02-2017
Proposal: A new INI file option for choosing the allowed protocols.
Rationale: Sane and non crashing defaults. #3201 is a major source of crashes (some are client side). Most players are better off playing a single protocol at a time. Those who want can change that default. We should make the crash avoidance tips thread irrelevant.
FAQ
Why not as a plugin?: 1. It is only a few lines of code. 2. Protocol whitelisting should be an integral part of Cuberite. Crash prevention shouldn't require a plugin.
Can't we have non crashing multi protocol support where items and entities foreign to older clients can be replaced with placeholders? We won't realistically have this any time soon.
Code:
Protocol=default # Allows the default protocol only, which is the best-supported protocol. Currently it is 1.8.
Protocol=ANY # Allows everything
Protocol=1.8 # Allows 1.8 only
Protocol=1.9 and up # Allows 1.9 and up
Protocol=1.8, 1.9 # Allows 1.8 and 1.9 onlyRE: Proposal: Allowed Protocols configuration - LogicParrot - 01-02-2017
Original wording edited slightly.
RE: Proposal: Allowed Protocols configuration - xoft - 01-02-2017
Sounds reasonable, though I object with the interpretation of "default". It should be considered a list of protocols that we know are "stable enough". In my opinion, currently the 1.8 - 1.10 protocols are stable enough to be used regularly.
This will also need some helper function for parsing the protocol versions to protocol numbers, possibly with range interpretation ("1.10 - 1.10.2"), which could be used for the "and up" ("1.9 -"). The ideal would be to have a function that parses the entire value and returns an array of protocol numbers, and a sub-function that parses one value from the comma-separated list and returns an array of protocol numbers it represents.
Also, the value should probably be called "Protocols" or even "AllowedProtocols", and its value should be logged upon server start, instead of the currently logged entire support (should we keep that?).
What about error handling - if there is an unknown protocol specified, should the server output an error and terminate? Seems like the reasonable thing to do.
RE: Proposal: Allowed Protocols configuration - LogicParrot - 01-02-2017
Quote:The multi-protocol support is not meant to allow different client versions to play together on a single server. The main point of the feature is to allow smooth transition - when a new Minecraft version comes out, we want to give the server admins the possibility to decide the exact moment when they move their server to the new version, while still keeping up with the new features.@xoft at Github.
To meet that demand, we could slightly modify the original proposal and ditch the "default" option. Whenever a server runs and the default INI is created, the setting defaults to whatever protocol is best supported at that time, and remains that way until the admin changes it. Newer installations still get the newer protocol and older installations can move to the next protocol whenever convenient.
RE: Proposal: Allowed Protocols configuration - LogicParrot - 01-02-2017
Quote:Sounds reasonable, though I object with the interpretation of "default". It should be considered a list of protocols that we know are "stable enough". In my opinion, currently the 1.8 - 1.10 protocols are stable enough to be used regularly.
Good point.
RE: Proposal: Allowed Protocols configuration - LogicParrot - 01-02-2017
Wouldn't specifying a range by default defeat the purpose? a 1.10 item can crash a 1.8 client.
RE: Proposal: Allowed Protocols configuration - xoft - 01-02-2017
Removing the "default" value and defaulting to the currently-best-supported protocol sounds like the best solution.