Net64 and Net64+ compatibility

[Tarnadas]

Net64 and Net64+ compatibility

This pull request will make them both compatible. You can connect with Net64 to any Net64+ server and vice versa. It will break compatibility to all older Net64 releases.

For any future releases, a backwards compatibility would be desirable, so I hope this will be the last time that we have to change the networking layer that much.

Switch from Hazel to WebSocket

You might already know why I did not want to use Hazel. Hazel is only implemented in C# and there are much better cross-platform solutions. WebSocket is an open standard that is used by a lot of programs. In fact it has some similarities to Hazel, but it is just so much better supported. There exists basically a WebSocket library for every programming language.

WebSocket uses TCP rather than UDP, so you would have to inform everybody about that change for port forwarding. I also think Hazel uses TCP for the handshake, so if someone tried to host without portforwarding UDP and TCP, it might not have worked. Now you would only have to port forward TCP.

Player Data Packets and Compression

Player data packets are now united in one large packet.

The player data per player has a size of 24 Bytes. Every player data is concatenated without any additional information, so you would have to know, that you must split the data every 24 Bytes.

Additionally Gzip compression is used to reduce sent bytes even further. Gzip is used by almost every website. It has fast and good compression rates. Gzip compression is only used for player data, because a Gzip header must be added, so if you just send a very small packet, the Gzip header size might rather increase the packet's size. With two players connected, the size with and without Gzip compression is about the same. With additional players, the packet size with Gzip compression becomes significantly less.

The update rate has been set to a fixed 24ms. With TCP, packets are guaranteed to reach the target server. Also Super Mario 64 runs with a native 30fps and 1 / 0.024ms = 41.67fps. We only have to keep that higher than 30fps. If you let users choose their own update rate, they might spam unnecessary packets to the server.

Make a clear split between Client and Server

The previous implementation felt really difficult to understand, because client and server stuff was mixed up.

In this implementation there is a server and a client. If you host a server, you basically connect as a client to your own server. This improves maintainability of the code, because we now have client and server separated.

Bump Major Version Number

Make it a 2.0 release. It has "incompatible API changes" and if you follow semantic versioning, you would have to do that.

I also added a compatibility version number, which is responsible whether you are allowed to join a server or not. Client and server must have the same compat version number. Otherwise a client won't be able to connect. No more crashes if someone tries to join with an older version.

Some small changes

• Set the max value of numeric up-down GUI element for max connections to 24. No more "max 64 players" servers...
• Every client now has an additional Chat textbox at the bottom.
• I tried to move a lot of the code out of Form1.cs. Form1 should only contain GUI related code.
• I might have forgotten something. Please let me know.

TODO

• Max connections are currently fixed to 24. Let the GUI element actually do something.
• UPnP
• Port check service
• Ban/Kick form

[Guad]

Awesome job! Thanks for contributing

[Tarnadas]

Before you make a new release, please don't forget, that resources are currently broken. I forgot to add that to the PR.

With the resources in the repository, you cannot play as Rosalina