Few Doubts about Join Server

[ravjotsingh9]

1) As you said Join Server should publish a list of Active nodes. What all thing shall this list include (I mean Ip:port or client Name. I think we should not include the agent name since that is the part of the game) ?

2) For Broadcast Action: I think our present version might not need the broadcast since that functionality is implicitly included in the design of the system. Actually, I used code from one of our assignment (assignment 3), where each node gets the list of all alive nodes. That list is published by Join Server via KvService. So, as soon as a node leaves the system, the activeNode list published by the Join Server (through KvService) will not include the node and will be removed by the servers as they receive the updated list in their next poll. If a nodes leaves game without following the game rules (I mean if it is powered off or something similar happens), the game shall simply remove it. I think since these scenarios are not the part of game, these could be handled outside the game semantic. But in cases where a agent (or node) has to leave game due to game action (due to firing), those shall not be handled by Join Server but by the servers themselves. What is your opinion ?

[Neo-X]

1) I think it should include the agent name. For Fire actions the client is going to need to know which server to send the fire action to. At this point we should include whatever we can incase we want to use it laster. Including the agent/client name should be easy.

2) Ya, great. I was thinking a broadcast only when the list changes, to save on messaging but it will be fast to just use what you said. That way we leave the respocability of maintaining each servers active-nodes list to the nodes. Not the Activity server.

[ravjotsingh9]

(1) Ok, I will include ip:port, clientName and agent Name, but I am bit concern about Location update of the agent. Who do you think should decide where a agent is ? There could be two approaches: a. Each server sends update corresponding to its own agent's location. But that could be compromised. b. Each server sends the list of all agents' location. Then how would Activity server decide which one is correct if there is a conflict. How would we ensure that all the servers send the game state at the same time ?

I think the game state is a distributed state and it could create problems if we try to converse the distributed states into single state at activity server. One other solution could be that when a node joins the game it does following:

1. Send Join Req to Activity Server.
2. Get its start location, clientName and agent Name in the response. [ Activity Server will allow its access to KvService in some way]
3. New Node poll for the list of the online nodes (as well as their ip_port, Client Name and agent Name)
4. Once it get the list then it requests each server for their state and decide on the basis of majority if there is any conflict. This approach might seems similar to the above approach but the only difference is that in above case (case b) the servers are updating their states at activity server individually when their poll timer expires( periodically) but in later case everyone will send response at the time when new node asks (which would be approximately at the same time for all the servers ) . In formal case, use of timestamp could limit the error to 't', which is a poll timer duration where as in later case the error is way less than the avg network time delay. What do you think ?

[Neo-X]

1) The activity server does not care about the state of the game. If it recieves an invalid message it is still a message and that node is still in the game. We can ignore that fact the messages the Activity server is recieving are location updates.

The activity server does hold ANY game state. The only thing it should keep track of if is a list of nodes that it has recieved pings from in the last 2 seconds.

The activity server does not need to decide on any state majority. Again it does not contain any game state. It only keeps track of who is logged in to play the game.

Maybe it would be clearer if we create a new message only for the activity server that is just the time from each node. This should be enough to maintain the list of active nodes.

UpdateLocation() messages are not sent to Activity server, only between nodes.

[ravjotsingh9]

Ohk, got it! But how would we pass the game state to a new joining member? I thought you want to keep track of location of agents in Activity Server so that we can pass that game detail to a new joiner. Am I missing something ?

[Neo-X]

The hope is,

1) When the new member joins the activity server will assign the new member a random starting location. 2) All members of the game will find out the new member has joined the game and will begin sending messages to the new member. This should get the new member synched up pretty fast. 3) When a new member joins there should be a small (maybe 2 second) wait period before it is allowed to start sending messages. This gives the new member time to collect the game state from other members (This is common in games when a new player joins, make them weight for a bit before they get to interact in the game).

I think this is also the easiest way, as it is the responcibility of the nodes to distribute their state.

[ravjotsingh9]

Awesome, that sound good! Thanks!