Jonathan Connell felt I did not support my case against Frame Locking well in the original answer and while it is a subjective matter, I believe I can present objective advantages in using an alternative technique to frame locking. While we all agree it could work for your game. It is by no means definitely the best or only was to achieve what you are are working to create.
So hear me out:
Minimizing lag in a RTS
RTS and action games are not the same animal. In fps, you constantly transfer tiny precise
movements to the server. RTS need to manage armies, sometimes hundreds of units where each unit needs to do path-finding, auto-attack(be aware of environment) and that means the units are somewhat independent. That is why people came up with Event-Locking.
With frame locking, the client sens an update every frame with the user's input. The sever processes input and replies with the result of all moves made by the players.
This method is great for low latency networks like home networks if you play with your friends through wifi without using the Internet.
This does not do wonders when you play online and there is latency, especially if your server is not ideal for multi-player gaming. This is without mentioning that the real world is not ideal, maybe one of the players is using a torrent client that is slowing the connectivity and causing additional latency and packet loss. Maybe another player has a poor connection, using a cellular device to play the game? Nobody knows what could happen during a network game online. That is why the system has to be as foolproof as possible. That is why I do not recommend frame-locking personally.
If all the clients send updates at the same pace things will work. What happens if an update is not received due to networking issues? The server and the rest of the clients need to 'freeze' and wait for that update. If the server and the other clients proceed the game will not be synchronized which is what we are working to prevent.
Depending on your game architecture, the player could see the results of her actions. What about the rest of the players, the packet did not make it, they do not see it.
You can adjust the system to compensate by adapting to the communication lag. This will make the system less responsive when there is a little more lag.
We need a system that avoids this, you are using a server, not all players need to be slowed down to the speed of the currently slowest player's connection.
Instead, it is much better to send requests for commands and moves. For example you have a commando you wish to move from point A to point B. The player who owns the commando unit will click it and then select to move it. The player issued the command with the destination, now the server is checking if the command is feasible. Maybe the player is a hacker or a cheater and does not have a commando, maybe the road is blocked and maybe the unit just died. If the command is accepted by the server after checking, the "Move(Commando,Destination)" packet is sent to all clients including the original player (as a seal of approval) with the time-stap and all needed data.
The same thing can be done with "Attack(Commando, Jeep)" commands and Collect(Harvester, resource) commands. You need to present resources as neutral units.
Not all clients will get the reply packet in the same time, remember the time-stamp?
To compensate for the delay, a client that gets the order too late, can either animate the unit slightly faster or "teleport" it to it's current correct location. On the player side the movement will start automatically assuming in advance that it is legal to prevent slow response time. If the movement is not accepted, the unit will move backwards which should only happen on very rare occasions.
Sometimes it will not be enough to send only the command such as Move(Commando, (x,y)) and you will need the server to send the resulting orders and way-points to all players.
That is because some new building or unit is blocking the shortest path.
I will elaborate if people feel this is valuable.