Hi,
I want to develop a mobile multiplayer game. (P2P - clients will communicate directly).
There won't be much data sent from one player to the other, but when there will, I'd like the change to appear in the devices at exactly the same time.

If player 1 presses a button, I thought to change his game state only after player 2 received and confirmed that he received the data, but then player 2's will be updated before player 1's...

Is there a way to get the state to change at exactly the same time?

Thanks!

There are two problems here. One is to synchronize wall clock time, either by using a centralized reference (say ntp), or to guessing from the round-trip time between the clients. The other is synchronizing simulation time, which is solved by using a lookahead. If player 1 presses a button at simulation time T, the change is scheduled to take place at time T+D where D is sufficiently large to be sure that this information has been transmitted to player 2.

There are two problems here. One is to synchronize wall clock time, either by using a centralized reference (say ntp), or to guessing from the round-trip time between the clients. The other is synchronizing simulation time, which is solved by using a lookahead. If player 1 presses a button at simulation time T, the change is scheduled to take place at time T+D where D is sufficiently large to be sure that this information has been transmitted to player 2.

Ok, but don't I need to make sure that player 2 received that message?
(I read that multiplayer games usually use UDP and not TCP...)

Yes, that's a third problem to take care of. If you use UDP you need to detect missing messages and make sure to resend them, while TCP takes care of this and guarantees to deliver the message eventually. But note that even if you use TCP you don't actually know *when* the message will be delivered, only that it will. So if absolute wall-clock synchronization is a requirement, you're right, you need to wait for that acknowledgement. (For games this requirement is usually relaxed, consistency and responsiveness is usually more important than absolute synchronization.)

The people are in different parts of the universe, and thus there exists no "exact same time." This is a simple matter of general relativity.
You might think the speed of light (and electrons) is fast, but once you involve the internet, it turns out, you have to design for this.
If the game is of the form "let whomever reacts first, wins," then you have to pre-schedule the presentation time, and measure it on each client, and send that measurment back.
If the game is of the form "let whomever runs over the health pickup first, gets it," then you will likely want to involve a central game server, and use various kinds of latency compensation to make the game mostly appear fair -- but there will be cases where some player sees something that didn't happen.
Only if you can accept a full round-trip-time of latency before the game simulation results show an actual action from a given game command, can you avoid those discrepancies.
Most RTS games do that -- they hide the latency with a "Yes, Sir!" animation before actually moving the commanded units.

So, what, exactly, is your gameplay? You have to design your game networking and simulation to match the gameplay you want, and there are game kinds that cannot be built over the internet, unless you accept that some player will sometimes see "snapping" or "impossible events."