LAN games with Synchronization

[Jasonholt]

In the context of a task, I develop a simple LAN network games. But there is a very specific requirement, I can not really get to hang with the normal development of network applications.

My players must agree on the position (score) and the position of the other players on the map. I think it's against all forms of logic, as in other forms of gambling serve I have been to work, it has always been the server as specified ultimate.

Immediate Bart, I would solve it by sending a Game State containing information about what player A sees when playing A move of his piece. And then send it on to player B and player C.

But the problem is what happens when more players are doing something together. How can we validate what is correct?

One solution would be for example. timestamps, but then clients do not AGREE since there would eventually be one that is more properly one of the others.

So I can not get into my heads how clients can agree on anything on a network. It should just be the server (game host) which provides (alm. simple broadcast).

Some ideas on what can be considered to be "agreed"?

[robodude]

You could probably create a system to remind token ring, it would not give the optimal result for the player, but it would be a solution.

[Ninja-X]

Are players or client agencies have agreed?

Players will probably require a post-trip model for the game.

Client agencies require a locking / synchronization mechanism so that only one of them can change the game state at a time.

[Jasonholt]

Are players or client agencies have agreed?

Client instances.

I have thought about the following:
Client A sends request to move OP (Board motion, a field at a time).
The server (host) verifies whether this is valid.
If it is valid, the server sends the movement to all clients, including client A.
Client A updates its own position when data is received.

But do not really know whether it counts as true synchronization.

[Ninja-X]

I am thinking of something like:

A server: request lock
server A: grant lock
A server: X
Server-B: X
B server: ack
server-C: X
C server: ack
(server releases lock)

[Jasonholt]

Yes, it sounds like a good idea.

But from a performance standpoint, it sounds reasonably ineffective.
Plus you have to queue the requests, I assume?

(It should be coded in java, but it should not mean anything.)

[Praetor]

Technical locking should not give so much overhead - less than 100 milliseconds.
Serialization of user actions will have a significant effect, but it is probably due to the requirements.
If you want to make a lot of functionality without the code too much, you could look at the JGroups.

[Jasonholt]

JGroups looks smart, but will probably try manual deployment to work with it on a more fundamental level.

Thank you very much