The first fact that any multiplayer game needs to accept is: "No matter how good your connection is, there will always be some unknown delay between the server and clients."
Because of this, contemporary real time networked games "run" the game on the server and the clients are just snapshots that are as accurate as possible, given any network latency. Because of the speed of networks, it just appears as though both clients are completely synchronized.
In the case of a pong game, the server would keep track of the ball and paddle's coordinates and periodically push this data to the clients. The server is also the one running the movement of the ball and collisions with the boundaries or paddles. Whenever the clients receive updates from the server, they override whatever data they have with the server's data and then render the game.
In return, whenever the clients receive input from the user, like a command to move the paddle, they send the inputs to the server and then let the server take care of the details of the result of that input.
For fast networks, this is usually enough, but what if you have a bit of a laggy connection? Do you want your game to freeze or appear choppy when the network slows down?
Many clients solve this problem by using Client Side Prediction. In a nutshell, this means that you are actually running your game on the client AND the server. Note that the server is the authority and any updates that the server sends overrides the data that the client has. If the network slows down, your client will continue to show a smooth experience to the user, but when a server update comes in and disagrees with the client, then the client will correct itsself by using the server's data. Really bad lag will still certainly make for jumpy movements in this case, but this smooths out most of the minor latency issues.
Here is the most helpful article I have found on the subject.
Also here is a post I asked about a similar issue which had some pretty good responses.