Rust/websocket for multiplayer FPS

Are there any best practices for building the server side of a multiplayer FPS in Rust/websocket.

Think something like the server side of Quake, except in Rust, and over websocket.

Mainly I want to learn what the main performance bottlenecks / sources of latency are, and how to avoid them.


Thanks to everyone for replies.

  1. Yes, the reason for websocket rather than TCP/UDP is: client is in browser (forgot to mention this above).

  2. Thanks, it does appear the higher orderbit is TCP vs UDP, i.e. websocket -> webrtc.

WebRTC might be interesting too.

1 Like

Yes, Websocket is the wrong technology for this. WebRTC is much better suited. This crate might be interesting to you (note that I haven't tried it myself, I only saw the announcement on the subreddit).

1 Like

I haven't used webrtc myself, but as far as I understand it enables browser to browser communication which would require going over the server in case of websockets. So for that specific use case, it surely performs better than relaying over the server, but if you have to go over the server (eg. to avoid cheating), afaict, websockets is a much simpler protocol and might well be better for performance.

That being said, the only way to know is to test/profile.

In my experience with message based communication (actor model), the bottleneck is thread sync in channels. If your server can run in a single thread without using threadsafe channels for communication you could potentially avoid this bottleneck.

1 Like

Simpler yes, but it uses TCP, which might be an issue if you need low latency communication, because TCP does reordering, retransmit, automatic bandwidth limiting, etc. If you plan to write a turn-based game (like Civilization for example), Websocket is the way to go, though.

There are many variants of network synchronizations for games, and whole books have been written about this topic. For example, for games like Super Mario and Star Craft, you need frame synchronization. FPS games usually add some frame extrapolation to smooth that over on the client side, with the server side being the final judge on hits. For both of these, you need UDP, and only WebRTC can provide that within a browser environment at the moment.

1 Like

Why not just use TCP straight, or UDP? I'd think TCP would be ideal, since the order of actions matters.

1 Like

You cannot make UDP or TCP connections from a browser. WebAPIs that you get are WebSockets and WebRtc.

1 Like

Ah, I missed that the poster was creating a fps in the browser.

1 Like

What if instead of a FPS I was developing a multiplayer web turns based game (so a different network traffic/latency tolerance)? WebRTC could be still a valid choice or better (easier) switch to WebSocket or maybe HTML SSE?

1 Like

While WebRTC could do it, Websocket would be much easier. SSE would also work, but isn't as well supported in middleware in my experience.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.