I've made a TCP-networked RTS, in which I passed the commands themselves, rather than the results of the commands. For instance, a player gives a move order. If the move order is valid according to that client, it is sent to the server. The server then sends it back to all clients, who validate and execute it.
So all client machines run the game themselves, the server code accepts messages and sends them back to all clients. If a client gives a move order, it won't start executing it until it is received back from the server.
The server sends a 'tick' number at which to execute the command as well, which is a few ticks ahead of the 'current' tick. This way all commands can be executed at the same 'tick' on all machines.
One benefit this method is that it doesn't depend on any individual client machine to validate the command. If I passed the results of the move, I might be able to hack it to move my units faster. All clients have to execute the same command and if one machine executes it differently, it will be obvious.
Validating the command client-side before sending it to the server isn't necessary, but in theory it saves network traffic. I used the same validation code to tell the UI that the move was possible, so it didn't require writing extra code.
As for what the messages might look like. I wasn't concerned with ultra efficiency as it was my first networked game. I passed commands as strings. The commands would be formatted like this: "<player_id>:<command>:<parameters>"
For a contrived example, a move command might look like this: "3:move:522:100:200". This means Player 3 wants to move unit 522 to (100,200).
The server passes the command on to all clients, including the one who sent it, with a tick number attached like this: "153238:3:move:522:100:200".
Then the clients would all execute this command when tick 153238 is executed.