Bandwidth requirements for online-matches

cola_colin · October 7, 2013

JackoNorm said: ↑

Australian internet is terrible. I live in the second largest city of this country and I'm lucky to get 700kb/s download and 60 kb/s upload. I can currently run the game alright, but will I be able to cope with post-release versions?
Click to expand...

I doubt the bandwidth usage will go up post release

supremeoverlord · October 7, 2013

UberWilliam said: ↑

For download, the server caps the amount of data it sends to any one client at 4mb/sec. The bandwidth cap is so high at the moment because we haven't had time to implement all the bandwidth optimizations we have planned. If you are playing late game and you notice that units move smoothly, stop moving for a bit, then jump forward you've bit the bandwidth cap. When it runs out of available bandwidth, it starts round-robining though the moving units sending updates for each in turn. (If you use ChronoCam to go back, it will fill in any missed info. If you go back over the same time span enough, you'll get a completely smooth playback without any additional bandwidth once it has finished filling in the missing info.)

There is negligible upload. Each command you issue is packed up and sent to the server, but the amount of data involved is trivial.

We could drop the bandwidth cap, but then people would hit it earlier in the game and whine about it being laggy. Come to think of it, there is no technical reason why we couldn't let clients tell the server how much bandwidth they want. If you have an expensive connection, you could make the choice for low bandwidth and extra lag over extra cash. Hmmm. I'll have to talk to the team about adding such a feature.

We will be improving our bandwidth usage and then dropping the bandwidth cap accordingly. Things like right now we are sending unit orientations as a quaternion made up of four full 32-bit floats. That is just silly. Sending all four components is unnecessary because they are all unit length, so we could easily reconstruct any one from the other three (plus a sign bit). Also, we don't need full float precision for the three remaining components. Something like 10 bits each for the first three components followed by 1 bit for the sign of the last component. 1/4 the number of bytes, per orientation.

But that kind of a change is an optimization of a system that is less than ideal, but works. Right now we are focusing more on stability (Hey, people paid to be able to play. I want them to be able to play. Not just look at a blank black screen. What is the fun in that?) and features.

By the way, some other differences between PA and SC&SC:FA (I wrote the networking code in all three):

in PA, each connection is completely independent. If you have a good connection and someone else has a bad connection, their connection won't degrade your experience. In SC&SC:FA, everyone had to handshake with everyone else, so if one player had a bad connection, everyone suffered. Furthermore, one player could grief the other players by unplugging their network cable, waiting a couple seconds, then plugging it back in before the kick timer expired. Go ahead and do that in PA. Nobody else will care.

in PA, the bandwidth demands are only proportional to the amount of stuff in the game and not the number of players. (Well, indirectly the number of players: more players playing tend to make more units.) In SC&SC:FA there was one message type that was sent O(n^2) times for an n player game. In fact, that one message type dominated the network traffic once n was more than 6 or 7 players.

no NAT traversal in PA. Our servers are all sitting behind public IP addresses and never make outbound connections. Each client connects to our server and never to each other. Simplicity. Also, that is exactly what web browsers and web servers do and if that doesn't work the user has bigger problems than not being able to play games. Every SC&SC:FA client had to be able to send packets to every other client. And given the crazy things various routers do in the name of NAT, getting all of them talking to each other can be quite challenging.

tl;dr: yeah it sucks now. We will be making it better.
Click to expand...

Why does everyone in SC:FA need a good connection to each other? Also could it be reprogrammed to be independent like PA?

cola_colin · October 7, 2013

Because FA uses p2p. So all players need to be connected to all players and send data to all players. I think the guys from FAF around ze_pilot work on creating a proxyserver that tunnels the p2p over a single server and removes redundant data. So yeah it can be optimized.

Bandwidth requirements for online-matches

cola_colin Moderator Alumni

supremeoverlord Member

cola_colin Moderator Alumni

Share This Page

Bandwidth requirements for online-matches

cola_colin Moderator Alumni

supremeoverlord Member

cola_colin Moderator Alumni

Share This Page

Useful Searches