Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate ways to reduce bandwidth requirements #22

Open
dazuma opened this issue Aug 2, 2015 · 0 comments
Open

Investigate ways to reduce bandwidth requirements #22

dazuma opened this issue Aug 2, 2015 · 0 comments
Labels

Comments

@dazuma
Copy link
Contributor

dazuma commented Aug 2, 2015

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)
@dazuma dazuma added the research label Aug 5, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant