You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, the main animation loop might be using a lot of bandwidth: the server sends a JSON payload to all connected players X times per second, even if nothing has changed. This is accomplished via a request-response loop. The client sends a "view_arena" request to the server, which replies with a payload describing all the arena objects. The client renders, and sends back another request. The client code is also throttled via window.requestAnimationFrame() to ensure that rendering isn't done more often than the refresh rate (usually 60 fps on most browsers).
Find a way to measure how much bandwidth this is actually using, and decide whether that's a problem, especially for large numbers of connected players.
If we need to reduce the size of our payloads, here are some initial thoughts:
Easy: Shorten keys in the JSON protocol. (e.g. instead of "heading", use "h".)
Medium-Hard: Make the protocol smarter. For example, if a tank has not moved since the last frame, maybe there's a way to express that more succinctly than repeating the same X, Y coordinates. Or if the tank is already moving at a constant velocity/direction, and that hasn't changed, then maybe the client can compute the new position rather than relying on the server. Finally, if there is no new information to send (i.e. all objects are stationary or "still moving the same way they were the last frame") then maybe there's a way not to send an update from the server at all.
Hard: Consider replacing JSON with a binary protocol such as protocol buffers. See https://github.com/bitwalker/exprotobuf for elixir, and https://github.com/dcodeIO/ProtoBuf.js for Javascript. Some notes here: on the server side, I believe Phoenix has a configuration that lets you replace the default serialization, but you may have to hack the Javascript on the client side. (Or you might be able to contribute a Javascript configuration mechanism back to Phoenix!) Also, make sure you benchmark to ensure that the serialization remains performant; we already know about surprising bottlenecks with JSON (tanx: frame rate drops significantly with 4+ players #11)
The text was updated successfully, but these errors were encountered:
Right now, the main animation loop might be using a lot of bandwidth: the server sends a JSON payload to all connected players X times per second, even if nothing has changed. This is accomplished via a request-response loop. The client sends a "view_arena" request to the server, which replies with a payload describing all the arena objects. The client renders, and sends back another request. The client code is also throttled via window.requestAnimationFrame() to ensure that rendering isn't done more often than the refresh rate (usually 60 fps on most browsers).
Find a way to measure how much bandwidth this is actually using, and decide whether that's a problem, especially for large numbers of connected players.
If we need to reduce the size of our payloads, here are some initial thoughts:
The text was updated successfully, but these errors were encountered: