Horizontal scaling is certainly a challenge. With traditional load balancers, you don't control which instance your clients get routed to, so you end up needing to use message brokers or stateful routing to ensure message broadcasts work correctly with multiple websocket server instances.
Hi I'm the author of this blog post and the CTO of Hathora. Happy to answer any questions about how we built our Stateful Router for WebSockets and other persistent connections!
WebSockets is built on top of TCP, whereas WebTransport is built on top of UDP. This makes WebTransport better suited for handling latency-sensitive applications like multiplayer games.
Does anyone know of any websites/applications that utilize WebTransport? The only thing I've come across are the Showcase demos from https://github.com/yomorun/presencejs
Hi HN, I wrote this article because I didn't find much on the internet comparing network performance between cloud providers. I was surprised to see the amount of separation between the top performers and the bottom ones.
We published our benchmarking script on Github[0], I'd love to see results from other geographies and perhaps even other providers like Linode and Hetzner!
If you're interested in using web technologies for your game, you may find the framework I've been working on to be interesting: https://docs.hathora.dev/#/
I've had success using it as the backend+networking stack in conjunction with game UI tools like Phaser and Pixi.js.
Hi there! I started a company this year focused on multiplayer server infrastructure. We also built a multiplayer game framework for Typescript that has gotten 400+ stars on Github in the past few months: https://github.com/hathora/hathora
Would love to connect and exchange notes about multiplayer development -- if you're interested, my email is on my profile.
I'm not the author of the game so not sure exactly what they meant by that, but that game uses Websockets which are built on top of TCP, so developers shouldn't have to deal with dropped packets (and our UDP implementation will have automatic retry built in as well)
Hathora actually supports raw TCP connections in addition to Websockets, and we're very close to shipping raw UDP support as well!
For the web, we're deciding between using WebRTC or leapfrogging straight to WebTransport[0]. Either solution would be a thin layer on top of the raw UDP work
Hathora's auth story is basically bring your own JWT token. So you can implement your own custom auth as long as you end up with a JWT signed using your APP_SECRET in the end.
Websockets do actually support binary packets not just strings. But yes you lose control over the server side receiver part of the connection (we think most developers will be ok with this)
Hathora Cloud will be able to run anything that can be packaged into a Docker container and implement the Hathora Protocol (yet to be formally documented)
It's close but TCP will retransmit frames rather than packing multiple updates in a single frame.
It's common for people to build this kind of retransmission logic on top of UDP (especially for networked games), it's sometimes referred to as "reliable UDP".
Exactly, you assign a sequence number to each update, have the client send acks to convey which packets it has received, and the server holds onto and sends each unacked update in the packet to clients (this is an improvement over blindly sending N updates each time, you don't want to send updates that you know the client has already received).
If the client misses too many frames the server can send it a snapshot (that way the server can hold a bounded number of old updates in memory).
I've been working on my own realtime networking engine[0] and I think there are a few important points related to network syncing that are not mentioned in this article:
1) Bandwidth. The users internet can only handle so much network throughput, so for fast paced games (where you're sending data to each client at a rate of 20+ frames per second) it becomes important to optimize your per-frame packet size. This means using techniques like binary encoding and delta compression (only send diffs).
2) Server infrastructure. For client-server games, latency is going to be a function of server placement. If you only have a single server that is deployed in us-east and a bunch of users want to play with each other in Australia, their experience is going to suffer massively. Ideally you want a global network of servers and try to route users to their closest server.
3) TCP vs UDP. Packet loss is a very real problem, and you don't want clients to be stuck waiting for old packets to be resent to them when they already have the latest data. UDP makes a major difference in gameplay when dealing with lossy networks.