New/Revised Protocol Discussion

[Starystars67]

New/Revised Protocol Discussion

This issue is to allow discussion to happen around a revised or even a new communication protocol for BeamMP between the launcher/game and the server.

I will update this first post with finalised items as they are worked out.

My Suggestions:

• The new protocol should have some sort of channel definition system. This would allow for messages to be broken up still and also maintain a level of security between them. For example we could have the following channels as a starting point:

stream (private) = Possible new channel for streamed data E.g. Lua, Other code maybe even mod data?
session (private) = All session related comms, players list, server name, ping, description, chat, events E.g. disconnect, update messages), other details?
plugins (public) = This channel is strictly for all plugin related comms, the comms over this channel would still be using a keyword for identifying
updates (public) = Vehicles, Unicycle, Map Objects

Note that public and private refer to if they can be accessed by the game or not. If it is private then only the launcher can interact with the channel and it handles the communication with the game.

• New download system over HTTP (Server change needed)
• New HTTP endpoint on the server which can have new routes/paths created from Lua for custom use and implementation. (Server change needed)

Final Protocol:

[lionkor]

For me, the protocol is more about finding a solid binary on-the-wire format and agreeing on a solid way of extending that. API versioning is another point. I would also like to have a better state management, so we have e.g.

pre-auth, authed, loading, joined, disconnecting, disconnected or something along those lines.

There are different layers to this - theres the layer right above tcp/udp that manages that, theres the application layer of what you Titch started writing about.

[lionkor]

I would have suggested shared code but that doesnt work since the server will be rust and the launcher c++. In that case we should write up a short and precise spec on how it works, including the tcp and udp.

Another point to consider is the udp session management (which doesnt exist rn)

[Lucky4Luuk]

Hey, I'm a few days late to the party, but protocol versioning is critical in my opinion. Currently it would be very difficult to make any changes to the protocol by just pushing an update to the launcher/server. If we can at the very least introduce protocol versioning, that would be great.

[Starystars67]

@Lucky4Luuk I fully agree. This is already done with the backend and auth however since there is no standard for communicating between the launcher and server I feel that this may need to be something new and not backwards compatible on this occasion.

@lionkor would you be able to share any sort of example for this binary communication? It would make sense for there to be a shared code but indeed as you said we use a variety of languages. This leads me to wonder could a library be created for this and then included E.g. as a DLL? (not sure if that is correct for rust, just spit balling ideas). I did find this for Rust: https://docs.rs/libloading/latest/libloading/

If we took this approach I feel it should be done in a cross platform approach from the start though.

[Lucky4Luuk]

I would really rather not have to load a DLL for the server. That would lead to unsafe code in Rust and that's really a route I don't want to go down.

[lionkor]

Agree with Luuk, no DLL. We can "just" write a spec and then all sides have to implement it.

As for what the format is, yeah, I have some ideas I will share in a bit here

[lionkor]

Moved to https://github.com/BeamMP/Future-Spec