This is where you need to sit down and work out what *needs* to be sent, in as little as possible.
Basically, you need to send as little information as possible - but possibly at 60 frames per second, this quickly mounts up.
Take a multiplayer pacman game for instance. To display everything correctly, you need, per player, their position (x and y as word values - 4 bytes) and the orientation (up down, left and right - 1 byte). So that's a total of 5 bytes, every frame. At a locked 60 frames per second, then you are sending 300 bytes per second. Not a lot, I have to admit, but then that is what ONE person will be sending. Now lets up the scale to 10 people playing at the same time - that's now 3000 bytes of information being sent to the server every second.
Now what about the information of the rest of the opponents? Well, that will be 9 people's worth of information. So, 5 bytes * 9 people is 45 bytes. So every second, you will be receiving 45 x 60 = 2700 bytes per second. So that isn't a lot for what the client will be receiving.
BUT, the server will be doing most of the sending and receiving. We've already established that it's receiving 3000 bytes per second, but it then has to pump out 2700 bytes to each person - thats then 27,000 bytes every second.
So on modern hardware - not a lot. Heck you should be able to (in theory) use a modem for that. But that is a very simple game.
Now if you upgrade that to a shooter, then the math explodes. You need to cater for *every* bullet position, type, power, as well as the player position, instructions (raise shield, powerup, etc). If you worked all that into 100 bytes per frame, then that's 6000 bytes per second to send and 54,000 bytes to receive on the client. On the server, it would need to be able to handle receiving 60,000 bytes per second and to send 540,000 bytes every second.
Obviously at this rate you will be needing heavy duty servers. Or you start to trim back to what you need and let the clients work out what was done as much as possible. You have Ghz of processing power but limited bandwidth - so retreating to math projections would be far more useful when you are going to be sending a stream of bullets all going in the same direction. You just send each bullet as it appears and it's trajectory and then all the clients will then know that the bullet will be moving per frame in a particular speed and angle. This massively reduces traffic.
I hope this helps
