Slashdot Mirror
Halo 3 Causing Network Issues
Recently at my university where I'm a student and a sys admin, we have been experiencing some odd outages, in particular since the 25th of September. The outages seemed to occur between 8 PM and 12:00 AM — peak gaming hours for our dorms. It just happens that Halo 3 came out on the 25th of September. Upon further investigation we found that our network routers were shaping TCP packets, but not UDP. Once we applied UDP shaping as well, all network outages ceased. Gamers complained, but university students attempting to access network resources such as our UNIX clusters were satisfied.
No in large university networks you have to set bandwidth caps for all users, (pst your ISP does this now and sets it at whatever Mbps you buy). His router wasn't even looking at UDP traffic so a few users were getting more than they were assigned.
Missed one - the routers crapped out on packets per second, not on bandwidth. This is probably the most likely one.
As far as the network protocols being abissmall you are about right. They have devolved over time.
Once past the stage of serial connections, the early gaming protocols efforts tried to use multicast+unicast or broadcast+unicast technologies to run peer-to-peers like networks where people truly played against each other.
These times are gone. It is all client-server now.
This explains the admin problem - I bet that most of the students were fragging each other silly together and played within the same map and the same game. That all ended up as a lot of client-server connections. This does not consume a lot of bandwidth on average, but it is capable of flatlining the network for short periods of time every time something interesting happened in the game because the data is tromboned back and forth across the same bottleneck many times. 1 student moves and the server sends the data to 16 others, and so on. Essentially this is a form of amplification/positive feedback loop. If the same students were playing games with other people located elsewhere the effect would not have occurred.
This is a classic example of devolving and microsoftization of the gaming protocols. If the game was running locally using broadcast+ unicast or multicast_unicast to inform all local participants and only one dedicated hypernode checked what is going on outside the small "local world" there would have been no bandwidth/pps problem.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
For a game, especially a FPS, you want to fully utilize available bandwidth.
I don't know of any FPS programers who would want to fully utilize available bandwidth. If they did, it wouldn't scale and their game would suck.
What they do want to do, is minimize latency to keep character movement smooth and accurate to give the perception of real-time immersion and do that with a minimum of bandwidth usage, so that their game will scale to a practical number of players. Minimizing bandwidth usage helps improve latency and scaling.
I must agree with this Coward. Some random university's network didn't have traffic shaping set up correctly. So? This is somehow newsworthy?
The Yasashii Syndicate ||
Just for the record, dropped (shaped) udp packets are not recovered. TCP/IP notices dropped packets, has them resent, and automatically lowers the connection's transmission rate, whereas with UDP you're just tossing EMP's into people's datastreams. UDP/IP is much more primitive, and relies on application level consistency checks, which, for the record, almost never ever ever monitor packet drops & throttle themselves down when packets start dropping. Thats why most packet filtering systems simply de-prioritize UDP and will not drop UDP.