search

Furball-Engine / Furball

A Game Engine designed in C# using a custom made Renderer called Furball.Vixie, uses a similiar design to the Engine peppy made while developing osu!stable
GNU General Public License v2.0
21 stars 2 forks source link

(WIP, will be updated frequently) [Feature Proposal] Furball Networking & Servers #13

Closed Eeveelution closed 2 years ago

Eeveelution commented 3 years ago

Writeup

Clarification: By Server I do not mean API or anything HTTP of the sort. By Server I mean a Game Server which is used for communication between players, multiplayer, etc.

There will be 3 Protocols supported:

Reasoning Being that WebSockets and TCP may not be able to handle very fast traffic which UDP is known to handle well. WebSockets is arguably the more secure given you can have it be HTTPS and it can get Cloudflare protection easly.

UDP

We will use LiteNetLib for both the Client and Server, due to simplicity of coding and low overhead while also having Packet Ordering and Reliablility. It also has pretty handy built in Packet Loss testing which could be very useful for testing.

TCP

It will be easiest to just use the built in TcpClient and TcpListener from System.

WebSockets

We will use Fleck for the Server and WebSocketSharp for the Client Reason for them being seperated is because WebSocketSharp's WebSocket server cannot be used in conjunction with nginx.

Serialization

There will be a Common Packet Serializer which will be just the basic Bancho Serializer, I intentionally did not consider JSON or any of the binary forms of it because of the Bancho Serializers very low bandwidth requirement, and partially because I am very familiar with the protocol and know how to implement it in a very simple way.

Implementation Server-side

There will be 3 Classes, all of which will try to share as much common code as possible, The classes for the Servers will be called:

Accepted Clients will be called:

All those will be implemented in custom classes so that you can have custom variables and potentially handling code

it is not called NetClient<protocol> because NetClient<protocol> will be the class instanciated which will be connecting to the servers. which I will defnitly get into later.

The NetServers will have have common methods like: .Start(string location, short port), .Stop(), and many others which im probably forgetting

I think that most of the Client Accepting will be abstracted, there will be a List of currently Connected clients and there will be a distinction between newly connected clients sending data and clients that have already been connected sending data.

Packet Recieving and Parsing will also be abstracted away. Packet handling itself will not, however the parsing and recieving will be abstracted. Most if not all the Abstraction will be able to be overriden to give the Developer the most control.

Both the Client and Server will have this, though Client's will need to have a slightly modified version of all this because Handling will be slightly different as it shouldn't be given a NetPeer as a parameter.

Packets will be defined with their Packet ID and the contents it's expecting. Packets will have a .Handle<T>(T peer) : where T is NetPeer<protocol> function. This will go both ways with slight modifications. The reason it has a generic type is because people will be using custom NetPeer classes and so that they can access the custom functions and variables they have there.

Implementation Client-side

NetClients will also have common methods like: .Connect .Send(Packet packet) .Disconnect()

Clients too will have Packet parsing and recieving abstracted nicely, so all you would have to do is write the Handling code in the Packet where there will be a .Handle<T>(T client) its a generic for the same reason as the Server.

Feature Proposal in progress, not everything is documented yet.

Eeveelution commented 2 years ago

not something i wanna deal with rn