This is the base trade-off in networked games. You either show predicted positions, and predict wrong, and have to "hide" it, or you show positions only when you have all the information, which means you show them "late."

One useful way of predicting is to not predict only on the given data, but instead, predict where the character will be when the next packet comes in, and interpolate between whatever the current position is, and that next-predicted position, over the time until the next packet arrives. Then, when the next packet arrives, predict where it will be when the next-next packet arrives, and move the character to that position over the next time interval.

The EPIC library (entity position interpolation code) implements this forward-prediction model, and shows that it's pretty smooth: http://www.mindcontrol.org/~hplus/epic/

What you describe sounds like the client is only interpolating between packets of data received from the server.

With such an approach smooth movement is hard to achieve:

1. Due to network latency, data displayed on the client side is never up-to-date. The client "lags".

2. Due to network latency, the packets don't arrive at perfectly regular intervals. Latency will cause "jumps" in your movement animations.

The better solution is to implement client-side movement prediction, as hplus0603 pointed out. With a good movement prediction algorithm, corrections will happen rarely.

Here's an article that explains the whole issue very clear and from a high level perspective:

http://gafferongames.com/networking-for-game-programmers/what-every-programmer-needs-to-know-about-game-networking/