So I've just started trying to make a multiplayer pong game and I have read a lot of different ways to code the connections. However, I read somewhere that you should have the inputs sent to the server queue up and then the server just processes it at fixed intervals. However, if this is done, how does the server know, process, and send accurate data based on the time the action was sent? Because if the data is just queued up, if something happens like 100 ms after another but the server processes them at the same time, wouldn't that mess up the synchronization of the game? Should the server instead be coded to handle the client actions immediately even if it costs a lot of cpu etc in larger games?
You don't need to process a packet immediately to know timing information. Just record the timestamp when a message is received, along with current latency measurements/estimations.
When you do eventually process the message you then know when the message originated. With the latency measurements, you can even estimate when the user initiated the action, e.g. if the server takes 50ms to process a packet and the network has 70ms of latency, you can estimate that the user pressed the key 120ms in the past.
This information can then be used by the server to alter its simulation. With pong, for instance, you can both set the paddle's velocity and teleport the paddle a little bit to account for the time difference. You can even rewind the pong ball and replay its collisions with the paddle after said adjustments, so the player is less likely to just barely miss the ball.
The client can do the same sort of time adjustment. It has an estimated latency to the server as well, and also can have estimated latency for the opponent. Using this information, the client can adjust the visual locations of the opponent or the pong ball. For instance, if the server sends an update on the ball position and direction, the client can extrapolate the ball's position using the estimated server latency.
Do be careful with doing both server and client time correction. It's hard to wrap your head around mathematically (it took me a while, anyway) and it's very easy to think you understand it when you really don't. Doing time correction on both server and client will exasperate any problems stemming from misunderstandings. I'd probably start with client extrapolation and build up from there, if you even need to.