But if we're talking about a first-person style game you have no idea what the destination is and polled synchronization is the only real solution I believe. Please correct me if there is another option I haven't considered.
you can still use a timestamp for an fps, collision must be performed serverside timebased, and client act a little like delayed "video player", no real collision on client side or only the currentplayer.
client1 send move x,y,z,t to x2,y2,z2,t2
client2 send move x,y,z,t to x2,y2,z2,t2
client3 send move x,y,z,t to x2,y2,z2,t2
server time know is min(t2/t) of the three clients, perform collision for all clients to min(t2/t)
server send to client all other clients position
clients display all other clients/players using server info, interpolating if currenttime < min(t2), or extrapolating if min(t2) is in the past.
as t2 sent by client will be close to currenttime or be in the futur, the "delay" introduced will not be a lot noticable for a displacement.exemple:
player 1 press up arrow to go forward than it must immediatly send to the server :
in case of a network lag, a client may need to know a player pos before server has sent it, so as cllient act as "video player" you need to extrapolate last know coordinates for an unknow player pos, and update it when server info are available.
I have notice something in the game battledfield when you loos server connection you can see other player continuing there movment throught building without any collision and you get stuck until connection come back (you can still rotate view, rotate view must be performed clientside as it request fastest response, I have experimented that and a delay on player camera rotation is very noticable).