Quote:

One is to move the players client-side all the time.




You don't want that.

Quote:

The other is to move the ents localy only until a regular update comes (thru a forced update) , wich will remove the 'build-in' lag of the frequency of updating.





This is where dead reckoning comes into play. Without DR, this routine will lead to very noticible (and unplayable) warping.

Quote:

Also , for the latency , it could be a 'many servers'




Unless you have to money to host a server on each continent, this is not a vible solution. If you have two servers in the same city (or even country), their latencies will be off by at most ms and thus you dont' gain anything here.

Quote:

When an ent moves , the client that owns the ent sends to all other nearby clients the input , and it will be ignored after a regular update comes




Here is an example problem here: Player A and Player B want to move to Spot A. Who gets to go there? What if Player C gets both updates? What does he see?

Here is another example problem: Suppose you have ten players and one server. One player moves and has to update the other 9 players as well as the server. However the server finds tht the movement was illegal and sends an update to all 10 players rejecting the move. However before you get the server update, you keep moving and giving the other 9 players updates. In short, one bad move could result in 10's or 100's of unnecessary updates which could lead to a flooding failure on the part of the client or server.

Peer to Peer is only good for 4 players or so without A LOT of overhead and completely impractical for 10 players or more.

Quote:

If the latency between the two clients is lower than thru the server , it'll lower the time needed for the packets




True, which is why so many MP FPS games use p2p... the latency is very low and not subject to a central server. However, as I've stated below, maintaining server sync and simulation integrety becomes, as you said, hard if not impossible!