Since the server is authoritative on position, this means that you will have significant perceived lag and an extremely poor user experience under many realistically sub-par network conditions.
While your situation is not as complex, I recommend reading older articles about the development of Unreal, Quake, and Counter Strike. I'm having trouble tracking them down now, and I apologize for my lack of Google-Fu, but all three engines had some excellent articles written by the developers back in the day on the precise difficulties they had creating smooth online play and how they resolved them.
Some points that I remember:
- When you take an input event, record the time of the event as related to the timestamp of the world that the player is seeing. So if the player is seeing frame 33271 when they press the shoot button, the event might be
33271:shoot that is returned to the server. This allows the server to take latency into account, and calculate things like 'at that moment, the player was aiming right at the enemy, even though 0.2 seconds later when I got the event they no longer were'. Without this, the player presses shoot and 0.2 seconds later a missile starts shooting from their ship. With this type of prediction, a player presses shoot and 0.2 seconds later the missile appears on their screen, but farther out as if it had already been traveling for 0.2 seconds. This allows for precise and responsive controls regardless of latency.
- Repeat important events until you get an acknowledgement. In the above example, every packet from the player to the server will include
33271:shoot until the client receives an acknowledgement of that event. If the first and second packet are lost, it will still get there in the third to be acknowledged. In addition, since the event is timestamped the server can still treat the attack as if it happened at the correct time, rather than being delayed due to network packet loss.
- The server should keep a state queue of the last second or so, so that it can determine the proper result of actions that happen in the past... 0.5 seconds ago, was the asteroid lined up with the laser blast? This reduces or eliminates conflicts between the player thinking they hit, but the server thinking they missed. Depends on the first point to work.
- Interpolate values on the client. Client side prediction is hard to get right, and can cause some warping effects, but is essential in creating a smooth experience for the player. Asteroids that are rotating will continue to rotate until disturbed obviously, and the client shouldn't need to get the location of the asteroid every tick. In the same way that client input is repeated until acknowledged, important game state changes should do the same from the server to the client.
I'm sure there are other considerations I've forgotten, and I apologize for not having links to the excellent and informative articles I've read in the past. Some (such as the ones I read about Quake World) are over 15 years old, when online gameplay was a new field. I suspect some of the articles I read were via the old finger protocol on Unix systems, a popular way for developers to interact with fans in the early days.