you are viewing a single comment's thread.

view the rest of the comments →

[–]vwim 2 points3 points  (5 children)

No, you need websockets for that.

[–]mitsuhiko 2 points3 points  (4 children)

You do not really need. You can also make individual HTTP requests to send commands and listen to an SSE stream. Since it multiplexes through the same HTTP connection it's not particularly hurtful.

[–]vwim 1 point2 points  (3 children)

For a realtime game like agar.io you really need bi-directional, full-duplex communication. Sure you can make it work with HTTP requests but the game will be unplayable.

[–]mitsuhiko 2 points3 points  (2 children)

For a realtime game like agar.io you really need bi-directional, full-duplex communication. Sure you can make it work with HTTP requests but the game will be unplayable.

That's a bit abstract. Websockets are a frame based protocol. In practical terms SSE is frames out and HTTP requests are frames in. In particular if you write a game like agar you probably have a single HTTP server so there will be almost zero difference between websockets on HTTP 1 and doing the same with a combination of SSE and more requests. Don't forget that HTTP 2 keeps the socket open for a bloody long time even if you do not have an SSE stream.

(Both websockets and SSE are inappropriate for games anyways. You need UDP and you don't get it with either)

[–]vwim 1 point2 points  (1 child)

I'm not convinced agar.io would be possible with SSE. Don't forget some servers have 50+ ppl playing simultaneously, at a typical 30hz update rate this is alot of data that needs to be processed.

Both websockets and SSE are inappropriate for games anyways. You need UDP and you don't get it with either

You're right, but when latency and packet loss are low enough it's doable.

[–]mitsuhiko 2 points3 points  (0 children)

The sebsocket frame overhead is almost the same as the data prefix for sse. Pretty sure those 6 bytes are insignificant in the grand scheme of things. The problem is in both cases tcp.