Unless it's an MMO, it's probably peer to peer.
Btw, peer-to-peer traffic does not increase exponentially. If you have n peers, where each peer has a connection to every other peer, then there are n^2 connections. That's only a quadratic increase. Far fewer than an exponential increase. Also, the more important point here, is that the traffic per node only increases linearly. That is, your own computer will only have n connections, even though the total number of connections between all computers in the entire system might be n^2.
I should also point out that any validity checks done by a server can also be done on each client. It's the same amount of coding either way. You write the checking code once.
The Server/thin client doesn't seem particularly relevant here. That would be like a web based game, where the web browser is a "thin" client, and doesn't know anything about the game, just how to display generic web pages. Not surprisingly, web browsers tend to be laggy and slow. The amount of traffic generated by such a game is usually quite large, and I wouldn't expect to find too many (if any) real time games that work like that.
If you want decent performance out of the game, you're probably looking at doing symmetric processing on all nodes, and just passing commands around. (NOP if they've done nothing, just to keep the timing and confirm that they've actually done nothing, rather than a packet was dropped). Usually, it's one packet type for every in-game command the player can order, but only so long as it actually updates game state. If there's a command to view some information menu, like the morale report, then other players don't need to know about that. It doesn't change game state, and so it doesn't need to be synchronized between computers. If they move a vehicle, or order it to attack, or self destruct, or for a factory to build something, then it needs to be sent to the other players. You'll probably want to do some filtering and dropping of certain commands to save bandwidth though (or rather, leave it to eventually time out and send a small NOP packet), such as they try to build something but don't have the resources. You might also want to drop certain move commands if it's redundant, such as telling the same unit or group of units to move to the same location. That also has the benefit of not having to run the path finding algorithm again, which is usually somewhat slow.
I should also stress the importance of pseudo random numbers here. If you send the same random number seed to each client, then you'll never have to send random numbers over the network, which can save significant bandwidth. If there's some melee of 100 units going at it, you don't want to be sending the huge number of damage values flying across the network (and would you trust them anyways?). Just initialize everyone with the same seed, and they'll all generate the same sequence of random numbers. Note that this requires the game engine to always use up those random numbers in the same order. So things like processing of players or units should be done in the same order on every computer. Don't just assume the local player is always processed first, and then all their opponents. You should probably just have everyone assigned a player number, and go through them in order each time, or something similar to this. (Perhaps process units in the order they were created, or the order they're placed in some internal array). This also has the benefit of making the game repeatable. This can be fun, in that it allows people to save replays of their game, but it's also very useful for debugging. If something goes wrong, they can save the replay (or an error handler can), which can be sent to the developer so they can repeat and track down the bug.
This also has anti-cheat properties, in that the only real way to "cheat" is generally by sending commands that a player could normally issue through the user interface. Mind you, you should do some sort of validity and sanity checks on the data. It's still possibly for them to say, issue a command to move a unit that they don't own. In cases like this, just check for these things, and drop the packet if it doesn't make sense. As long as you check for dumb things like this, it's pretty hard to cheat, short of making some macro/bot to play the game for them with unusually fast decision making. Of course, bots usually suck in comparison to real players at high level strategy, so they probably won't be winning out here anyways if they try this, unless they can still effectively interact with the game, and are also good players to begin with. Btw, those recorded games can also catch and prove someone was cheating if they do find a way to send invalid packets that didn't have proper validation code.
Real time games also likely use UDP, rather than TCP. Generally, TCP is too slow, and too overkill for a real time game. TCP has simplicity advantages with the timeout/auto-retransmit, but it's implemented using ACKs and NACKs. With bursty traffic, such as web browsing, ACKs are important, since the sender sends stuff unexpectedly, and it won't know if it's packet arrived, unless it receives a reply. In a real time game, you're sending packets constantly, at known time intervals, so you'll know if a packet was dropped because it won't arrive on time, and so you won't need to ever ACK. If the packet arrives by the time it's needed, then continue on, otherwise, the game has to pause while you request a retransmit. Although, you don't always have to wait that long before requesting a retransmit. If you know about how long you should have to wait, then you can make the request a little bit earlier than you need it, or if you're queuing a number of packets and one seems to be missing (i.e., you've received the later packet, but not the earlier packet), then a packet was probably dropped and should be rerequested.
You can also use the average timing between packets to set the game speed. If the game speed is set to run faster than the packets are arriving, then it will be pausing for each one. That can result in jerky performance. Particularly if the packets aren't arriving at perfectly even intervals, which is usually the case. If you've ever done any statistics in highschool, such as z-scores and bell curves, this might be a good area to apply that knowledge to.
I remember one of the best articles I read was about the design of Age of Empires. I just googled for the paper, and I came across this:
http://www.gamasutra.com/view/feature/3094...88_network_.php, which seems to be what I read, or at least very similar to it.
