Considering a p2p udp application for only 2 people, I want to send a packet to the other box connected in wich it's described the keys I pressed. Now I fill the packet with the time d in wich the keystroke is catch. Consider this: 1) time d -> keystroke detected -> send packet 2) time d + ping-time -> recieved packet of time d -> send an ack response If I want to make the two clients in synch when I can perform the action derivated by the keystroke described in the packet? The client recieving the packet cannot perform immediatly the action cause he cannot know when the other side will recieve the hack. What is the solution to this problem?

You cannot know that the machines are always perfectly in sync. For example, the packet may get lost and need to be re-transmitted.

One thing you can do is to measure the round trip time, and then queue all commands to be executed one RTT (or slightly more) in the future. However, you don't actually progress the simulation unless you've gotten an acknowledge of your command in time. If a packet gets dropped, or delayed, you have to temporarily pause the simulation (you can still draw animations and stuff). This is the model used by most RTS games with online play.

so there is no way to handle perfect synch? I'm lost. Imagine a game in wich the input are very important like fighting game. Taking a puch or not can deliver to an end of the game or not. If I start simulation and the game end (for player 1) if the player 2 lost the packet for him the game doesn't end.

You are never perfectly in synchronization because you are updating the other computers on an approximization! You are sending updates a few times per second, while your game is likely updating 30 - 100 times per second.

The objective is to make the user think everything is running smoothly, mainly in between the times you get updated information, and to relax that information so changes aren't radical.

Games where player A needs to react to actions from player B with split-second accuracy (say, typical fighter games) just aren't going to translate very well to high-latency set-ups. Doing ping pong over the Internet is unlikely to work well; doing real tennis is much more feasible, because the delay between interactions is bigger.

FPS-es sidestep this problem, because interactions are mostly one-way, and the two-way interactions (kills) are imprecise enough that the lag can be hidden (i e, you don't know exactly how many of those bullets "should" have hit).

http://www.codewhore.com/howto1.html

-cb

so no perfect synch is praticable. I've read the link posted and I can say that build an array of the last 60 ping time and perform an approximation is the best way actually existent.
Consider this:

HOST#1 (time T)
send (packet time T)

HOST#2 (time T + D1)
recieved (packet time T)
queue action at (time T + (average of the last 60 ping / 2))
send ack

HOST#1 (time T + D1 + D2)
recieve ack
execute action

so we can only hope that D1 = ~(average of the last 60 ping / 2)
I'm right? Or I'm missing something?
Now that I'm thinking about this I understand why in the game called "Warcraft 3" there are a 5 seconds countdown before a match. I think that in this time the host calculate the average ping between each players. I must fire up nmap and take a look.

Considering my precedent post I can I handle packets lost? For me there's no way to handle this..