Quote:Original post by John Schultz
This makes sense for objects that are rapidly changing state when the system is not running lock-step (or don't require ordered state consistency). To date, I have not run into a problem where this method can provide significant bandwidth savings, but I'll keep it in mind as a future option.
We've found that this method is useful for almost all simulation objects in the 3D (or 2D) world. Players, projectiles, vehicles, etc, whose updates constitute a substantial amount of the server->client communication. In reality it doesn't "save" bandwidth, rather it allows you to more optimally use the bandwidth that you have. Because you're not guaranteeing that any particular data are being delivered, the network layer has the latitude to prioritize updates on the basis of "interest" to a particular client. This results in a substantially more accurate presentation to the client for a given bandwidth setting.
Quote:
Given that this thread is titled MMORPG..., have you tested TNL with 2000-3000 player connections, under real-world internet conditions?
The largest "real-world" games we tested with were 100+ player "single zone" Tribes 2 servers. The problem domain is slightly different - i.e. Tribes was a twitch shooter with substantially more interactivity than most MMO type games, but it should translate well into the MMO type domain.
Quote:
Worst case scenario analysis for a MMORPG and 3000 very active players:
3kbytes/sec * 3000 players = 9000kbytes/sec, 72,000kbits/sec, 72Mbits/sec.
This means you'll probably have many fat pipes, as well as extra routing capabilities to deal with varying internet conditions. Given the unpredictability of network conditions, if the server does not actively adapt its bandwidth output, the system is going to fall apart (lots of data, lots of connections, lots of unpredictability).
It seems to me that an MMO service provider is going to want to make sure that it has enough bandwidth to handle peak load, with a healthy margin. It would be a trivial addition to TNL to allow a server-wide maximum bandwidth setting (i.e. 50 mbits/sec) and then adapt the fixed rates for all connections down as new clients connect.
Quote:
Thus, I hope it is clear why I have been defending TCP*: it really is an excellent protocol. Some of its features are not ideal for games/simulations, but the RTO calculation (see appendix A in Jacobson's paper) is required if a custom protocol is to be used in a large-scale, real world internet environment (such as a MMORPG). It's probable that the UDP-based MMORPG's that fail/fall-apart is due to poor bandwidth management.
Yeah, TCP's got some good bandwidth adaptation features. But classifying all data as guaranteed makes for big simulation trouble when you inevitably run into packet loss.
Quote:
In summary, study the history and design of TCP, and use the best feature(s) for custom game/simulation protocols, while leaving out (or retuning) features that hurt game/simulation performance.
Good summary!