Dissonance version seems to affect client-server interaction

[awonnink]

Context

We use LLApi with a dedicated Unity instance on a server to function as Dissonance server. It seems like for every upgrade of Dissonance for the client, the Dissonance version on the server has to match.

Expected Behavior

As the client software is going to be distributed, we won't be able to assure that al clients are on the same version as the server. One would expect this communication not to break between Dissonance releases, except perhaps for major upgrades.

Your Environment

• **Dissonance, now on 6,0.2
• Unity version: 2017.3.1P3
• Editor Operating System and version: Microsoft Windows 10 Pro 10.0.10586 (x64)

[martindevans]

We've intentionally never made any stability guarantees about the network level protocol of Dissonance. This was to allow us to rapidly iterate on adding new features without constantly bumping the major version. With Dissonance 6.1.0 (released today) we made a change to the encoding of 16 bit integers (swapping the endianness from little endian to big endian) for the sake of consistency (all encoding on the network is big endian). This helped out someone who is completely rewriting the Dissonance server (in another language).

However I think it's long past time that we change this policy. We've reached a level of stability where we can reasonably include the network protocol in the stability guarantee.

Any future incompatible network protocol changes will be associated with an increment of the major version number.

[awonnink]

Hi Martin,
Perhaps you can consider to always try to program with backwards compatibility from a certain version on with respect to this issue, even between major versions. Otherwise upgrades will become very difficult in a live system.

[martindevans]

We'll certainly try to keep breakage to a minimum - we don't like bumping that major version number! We don't anticipate making any more breaking changes to the network protocol, we've expanded it to the point where we should be able to add new features in a backwards compatible way from now on (adding new packet types which older clients simply ignore).

When we make any breaking change (which now includes network protocol changes) we make sure to tell you exactly what incompatible changes were made with the last version in the release notes - e.g. with 6.0.0 there were two changes, as you can see from the 6.0.0 release notes. So make sure to look at those (you have to go there anyway to download the integrations).

Something else I'm considering is a protocol version number in packets. Dissonance already includes a magic number in the header of every packet purely for sanity checking (it's the first thing read from every packet, if it's incorrect the packet is immediately dropped). We could increment this number every time we make a breaking network level change, this would mean that if an incompatible client tries to connect to the server it will fail (better than it connecting but with a subtly different protocol, which could cause all kinds of madness).

[awonnink]

Sounds good, and great responsiveness as always!
Albert Jan