I've heard differently in other networking posts.
I don't have experience here (never made online multi-player but I plan to) - but I heard something about a combination of "techniques" to make it work.
1: One server trying to do physics for everyone - might be tough - depends on game. (Imagine a small little go cart track - 4 cars - ok - maybe ok - now imagine Far-cry'ish - 10 guys - different areas of map - and each blowing stuff up - could BOG down hard)
2: Packet latency is a constant problem. One technique it to anticipate each player's movement based on last position, rotation, speed... and try to keep that going until a "Correction" makes it to ya. This is how I think I heard halo does it.
3: Physics for explosions etc. Probably some creativity is needed here. First - processing physics NEAR your camera on yuor machine (even other players) makes some sense. So if something blows up - you both see it all "blast and fall, and push and whatever" but if another player (an result explosions, damage) happen far away from YOUR camera - you MIGHT want you're physics to not calc it, and then the player who did the damage sends a packet that it was done, and they systems sync up on what's going on with surrounding objects.
I don't know but its not as simple as one server if you want a lot of stuff happening.
Other strategies (in general) are to REALLY LIMIT what is effected by physics and what isn't... maybe even user settings - like "Fast PC, Med, Slow" etc... but also for LAN play.
I think this part of the game making process 1: needs to be tightly integrated into the game mechanics from the ground up.... and I also think everything you do in the creation of the game needs to fully be thought out as far as how it will could impact multiplayer/online anything, and make ways to deal with each in the fastest code execution method available being careful to not bog down your packets with needless data if at all possible.
