It's hard to tell for sure from the information given but it sounds like what you are trying to do is make the client and server run deterministic code such that if they start with the same starting state and process things on the same loop numbers that they will result in the same values for the same calculations. Is that correct?
One thing you are doing correctly is that you seem to have an update function that doesn't use elapsed time to do calculations (like how far something moves). That makes it frame rate independent which is important for preserving determinism.
However, it looks like you are relying on server code and client code to come up with the same results for the same code. That is tricky to get right using floating point math, and I believe is impossible if you ever use things like sine and cosine.
Anyways, you are going to have a heck of a time making sure client and server always match up, even if you find a way to share code between the two without copy/pasting code or implementing every feature twice (both of which are error prone and make a lot of work!)
I think your better option would be to have one side (client or server) be authoritative and have the other side interpolate between data it receives.
In games with a low number of players in a match (like an fps where you can have up to 16 players), the server being authoritative is pretty reasonable and is more secure against cheating.
In games with high player counts (like MMOs), its usually the client that is authoritative believe it or not, and the server just makes sure a player isnt moving more quickly than they should be able to, jumping higher than they should etc.
Let's say he server is authoritative. You could have the client use dead reckoning and also player input to guess where things are going to be and extrapolate data. When the server sends an authoritative answer about these things though, the client would either need to "pop" the values to the right values or blend to the right values over a short amount of time to hide the fact that it was wrong.
Another way though would be for the client to be one simulation frame behind the server, so it always has knowledge of the last and next frame of data, and it can interpolate between those sets of data. Going this route, there is no wrong extrapolated data, but there is some input latency added. (Which you can again hide with client side prediction to get a blend of the two solutions!)