The system doesn't have to be imprecise or messy. And there's no reason why the authoritative simulation should not be perfect. But you do have to accept that information takes time to travel, so you either:

• wait for it to arrive, and wait for a reply confirming it arrived
• assume it will arrive, and act on that assumption, being ready to correct the assumption later

It's totally possible for a client-side simulation to exactly match the server-side simulation - providing it waits for all data from the server before performing any simulation! That is totally workable in some cases (e.g. Chess or other slow-paced games), it's something you can pretend to do with some game types (e.g. RTS where you pretend to start the unit's order locally but actually wait for a server response before starting the move), and impractical/impossible with others (e.g. FPS where you really must move the local player before the server will have time to confirm). It's all about the tradeoffs.

Quote

 

there's no reason why the authoritative simulation should not be perfect

 

 

If your runtime is JavaScript, you might not be able to get perfect determinism across all browsers and platforms, because JavaScript only has double precision floating point numbers, no integers or anything like that. Double precision can be deterministic if everyone runs the same binary on the same CPU architecture, but that's not true of the web.

It is also possible for peer-to-peer systems to have each client simulate the state of all the other clients, and "vote" on which other clients may be attempting to cheat. This works, until the cheaters outnumber regular users in some particular game instance, at which point cheaters win the vote. If score (or resources like gold etc) are important in your game, cheaters will find a way to set up a ring where they all collude.

The final nail in the coffin for large peer-to-peer games (where "large" means "N > 2" pretty much) is the growth in packet overhead. If you have 100 players, then you need to send your state, every tick, to 99 other players, and receive their state, every tick, from 99 other players. The packet overhead and overhead in keeping those connections open is massive. Meanwhile, in client/server, you only have one connection open, to the server, and you send to only one remote system, the server. You receive from only one remote system, the server, but you do receive 99 different states, packed into a single packet, so the overhead is cut down a lot. For many games, the TCP packet overhead (40+ bytes) is bigger than the payload-per-player, so this really matters. Also, most residential internet has much faster downlink than uplink performance, so sending as much as you receive (99 streams times one packet per stream per tick) will run into the uplink limitation much sooner as the game scales up.

Okay, I broaden my statement to "there's no reason why the authoritative simulation should not be perfect, given the use of correct platform-independent data types and proper accounting for precision limitations". It is a non-trivial issue which is why I prefer to avoid it by not using peer-to-peer systems.