The details depends on the scale of the game. for a smaller scale not really RTS game that was first to multilayer you can check out netrek. I would be careful about using existing games as "good" examples as most of the network code out there truly sux. Most of it was written by people who clearly knew nothing about networks.
Anyway here is my $2 worth.
If the scale of the game means that a state update is large (say 1000 of units) then synchronized simulation is the only way to really go. The network is still the bottleneck and you only need to "transmit orders".
Comerical RTS games use a P2P network connection pattern which is pretty terrible as for 4 players you have 16 connections and only one need to be bad to lag the whole game. They get away with it because most games are 2 player, and most 4+ players are typically lan players.
Server is the way to go. But as you suggested a player hosts the server. 4 players mean 4 connections so its less likely to lag. However the server player gets to see things in the future ever so slightly. Even on a lan this is generally more stable.
Finally we have TCP/UDP arguments. Most of the time people just say UDP "because its faster". This is not generally true. In some instances TCP is faster due to the stateful connection --NATs, firewalls and routers can "cache" and compress TCP packets and often do.
For a synchronized simulation TCP preserves order and has reliable transport *and* has flow control. So i would always start with that. Really pings across the EU and even to NZ were the same for or better for TCP compared to UDP.
Now I have a large scale (1000 of units) RTS game with 2-16 players. I use synchronized simulation with a server client architecture.
A client may issue a command. Say "send these 100 units to position x,y". This is sent to the server, the server schedules the command into a game turn, then sends out all the commands from all players for that turn. The clients then put the commands into their game turn schedules. Game turns commence at about 5 per second currently. Note that schedules can and do lead games turns slightly. It should be quite easy to see how the "network" controller, and or local controller can plug into this model. Synchronization is achieved via discrete game turns.
The trick here is that a lot of behavior is "local" to the unit. ie its not a command. If a unit is on guard, it will attack anything that comes close, the client does not need to send a command for this. Same with formation behavior etc.
There are details. like a client predicts what game turn the command will end up on and makes the units move --resyncing later if needed. This reduces the "apparent" lag.
Only last thing. If you use UDP and you resend packets. You *must* have flow control.
