The Forum FAQ mentions that you either delay the local user, or forward predict (extrapolate, dead reckon) the other user. It also links to the Entity Position Interpolation Code code sample. Although it's in C++, it does show the math involved, and has a sample test program.

How you synchronize also depends greatly on what is being synchronized and how important time-critical it is. If it is a slower-paced game, you can often get away with event-based updates - that is, when player X moves, you send the information stating they have moved. You can also use TCP for this since resends are actually wanted (nearly) every time. If it is faster-paced, though, like a shooter, you will probably want to use UDP so you don't have to resend dropped packets, and constantly dish out information on the state of every entity. Information that is lost from dropped packets is just replaced shortly later by newer information instead of waiting around for the old information to be received before making use of the new information. This will result in a lot more bandwidth but a lot better synchronization.

The FAQ also goes into great detail about "TCP vs UDP", when to use each, etc.

When you say the positions are not equal in your second paragraph, is this after they have finished moving? Or while they are moving? If the latter, it is something you should expect for any networked game and can't be "fixed" but rather just "covered up" by using techniques like hplus mentioned. If its not synchronized when they are not moving, simply include that information. Include their current position, velocity, and any other relevant information to properly simulate the movement.