NetworkDesign: Difference between revisions

Jump to navigation Jump to search
← Older editNewer edit →
Content deleted Content added
No edit summary
No edit summary
Line 87: Line 87:
The login Message is sent from the Client to the Server to request the right to access to the game. The message is composed of a username and password. The Username is a string that is already registered on Server as the name of a user account, and password is a string that is associated with that account. If the username/password combination is correct then Server must send a Login ACK Message to indicate to the Client that the message has been correctly processed. On the contrary, if the username/password is wrong the Server will send a Login NACK.
The login Message is sent from the Client to the Server to request the right to access to the game. The message is composed of a username and password. The Username is a string that is already registered on Server as the name of a user account, and password is a string that is associated with that account. If the username/password combination is correct then Server must send a Login ACK Message to indicate to the Client that the message has been correctly processed. On the contrary, if the username/password is wrong the Server will send a Login NACK.


!!Message S2C Login ACK
==Message S2C Login ACK==
The LoginACK Message is sent from the Server to the Client to indicate that the login process has been completed correctly and that it can proceed to the next step. It has no params.
The LoginACK Message is sent from the Server to the Client to indicate that the login process has been completed correctly and that it can proceed to the next step. It has no params.


!!Message S2C Login NACK
==Message S2C Login NACK==
The LoginNACK Message is sent from the Server to the Client to tell the Client that its login message is incorrect because either the username or password is wrong or because Server has decided to reject the login request, e.g. if the Server is full or because the IP is banned.
The LoginNACK Message is sent from the Server to the Client to tell the Client that its login message is incorrect because either the username or password is wrong or because Server has decided to reject the login request, e.g. if the Server is full or because the IP is banned.


The message is composed of: Message indicating the resolution.
The message is composed of: Message indicating the resolution.


!!Message S2C Character List
==Message S2C Character List==
The ~CharacterList Message is sent from the Server to the Client to give the Client a choice of character to play with. This feature models the behavior of having several characters associated with a single account.
The CharacterList Message is sent from the Server to the Client to give the Client a choice of character to play with. This feature models the behavior of having several characters associated with a single account.


The message is composed of: A List of Character names
The message is composed of: A List of Character names
Line 102: Line 102:
Each character name must be unique at Server level, and it is assigned when the character is created.
Each character name must be unique at Server level, and it is assigned when the character is created.


!!Message S2C Server Info
==Message S2C Server Info==
The Server Info Message is send from the Server to the Client to tell the Client about what Server is running, and how to inform Server administrator of problems.
The Server Info Message is send from the Server to the Client to tell the Client about what Server is running, and how to inform Server administrator of problems.


The message is composed of: A List of strings of the type "attribute=value"
The message is composed of: A List of strings of the type "attribute=value"

!!Message C2S Choose Character
==Message C2S Choose Character==
The ~ChooseCharacter Message is sent from the Client to the Server to indicate what character the user wishes to play the game with.
The ChooseCharacter Message is sent from the Client to the Server to indicate what character the user wishes to play the game with.


The message is composed of: the name of the character
The message is composed of: the name of the character
Line 117: Line 118:
Once a character is chosen, the only way to choose a new one is by logging out and logging in again.
Once a character is chosen, the only way to choose a new one is by logging out and logging in again.


!!Message S2C Choose Character ACK
==Message S2C Choose Character ACK==
The Choose Character ACK Message is sent from the Server to the Client to notify the Client that the character has been chosen. The message is composed of: the object.ID of the character
The Choose Character ACK Message is sent from the Server to the Client to notify the Client that the character has been chosen. The message is composed of: the object.ID of the character


We need this value to track our own character.
We need this value to track our own character.


!!Message S2C Choose Character NACK
==Message S2C Choose Character NACK==
The Choose Character NACK Message is sent from the Server to the Client to notify the Client that the character has not been chosen. This also implies to the Client that it should send another ~ChooseCharacter Message.
The Choose Character NACK Message is sent from the Server to the Client to notify the Client that the character has not been chosen. This also implies to the Client that it should send another ChooseCharacter Message.


It has no params.
It has no params.


!!Message C2S Logout
==Message C2S Logout==
The Logout Message is sent from the Client to the Server to indicate that it wants to finish the session. It has no params.
The Logout Message is sent from the Client to the Server to indicate that it wants to finish the session. It has no params.


If the Client can logout the Server will send a Logout ACK Message and the Client can safely close the connection, but if the Server sends a Logout NACK Message, the Client should keep playing as disconnecting at that moment will leave its avatar in the game uncontrolled ( idle ).
If the Client can logout the Server will send a Logout ACK Message and the Client can safely close the connection, but if the Server sends a Logout NACK Message, the Client should keep playing as disconnecting at that moment will leave its avatar in the game uncontrolled ( idle ).


!!Message S2C Logout ACK
==Message S2C Logout ACK==
The Logout ACK Message is sent from the Server to the Client to notify the Client that the logout has been accepted.
The Logout ACK Message is sent from the Server to the Client to notify the Client that the logout has been accepted.


It has no params.
It has no params.


!!Message S2C Logout NACK
==Message S2C Logout NACK==
The Logout NACK Message is sent from the Server to the Client to tell the Client that the logout has not been accepted, possibly because something related to the RP entity, for example, combat is in progress.
The Logout NACK Message is sent from the Server to the Client to tell the Client that the logout has not been accepted, possibly because something related to the RP entity, for example, combat is in progress.


It has no params.
It has no params.


!!Message C2S Action
==Message C2S Action==
The Action message is sent from the Client to the Server to notify the Server of the Clients desire to execute an action. The message is simply composed of a single action.
The Action message is sent from the Client to the Server to notify the Server of the Clients desire to execute an action. The message is simply composed of a single action.


Line 150: Line 151:
It has 1 param: action_id - is used to identify to which action you referred. In Marauroa you can command several actions per turn.
It has 1 param: action_id - is used to identify to which action you referred. In Marauroa you can command several actions per turn.


!!Message S2C Perception
==Message S2C Perception==
The Perception message is a message sent from the Server to the Client to notify the Client about changes to the objects that exist near it. The message is based on the idea explained in Delta perception document.
The Perception message is a message sent from the Server to the Client to notify the Client about changes to the objects that exist near it. The message is based on the idea explained in Delta perception document.


The message is composed of:
The message is composed of:
*A type that can be DELTA or TOTAL
*A type that can be DELTA or TOTAL
*A string indicating the name of the zone the perception is related to.
*A time stamp value that will be just one unit bigger than the previous perception
*A time stamp value that will be just one unit bigger than the previous perception
*A List of RPObject that contains added object
*A List of RPObject that contains added object
Line 164: Line 166:
Read the Delta perception algorithm to understand what it is for.
Read the Delta perception algorithm to understand what it is for.


!!Message C2S Perception ACK
==Message C2S Perception ACK==
The perception ACK message is sent from the Client to the Server. We use this message to inform the Server that the Client is still there and listening. It has no params.
The perception ACK message is sent from the Client to the Server. We use this message to inform the Server that the Client is still there and listening. It has no params.


!!Message C2S Map Hash
==Message S2C TransferREQ==
The TransferREQ message is a message sent from the Server to the Client to notify the Client about the request of the server to send content useful for the game where play will happen.
(TODO)


The message is composed of: An array of TransferContent objects containing all the name of each resource, its timestamp and if the resource is cacheable or not.
!!Message S2C Map
The Map message is a message sent from the Server to the Client to notify the Client about the content of the map where the game play will happen.


==Message C2S TransferACK==
The message is composed of: An array of Byte containing all the raw data.
The TransferACK message is a message sent from the Client to the Server to notify the Server about what of the given TransferContent elements recieved from TransferREQ should be sent.


The message is composed of: An array of TransferContent objects containing all the name of each resource and a flag indicating ack or not.
This message is totally game dependent.


==Message S2C Transfer==
!!!Network Manager
The Transfer message is a message sent from the Server to the Client to send the Client content useful for the game where play will happen.
Last updated: 2003/09/26


The message is composed of: An array of TransferContent objects containing all the name of each resource, its timestamp, a flag indicating if the resource is cacheable or not and a byte array with the content itself.



=Network Manager=
The Network Manager is our router that sends and receives messages to and from the network. The manager exposes the interfaces that allow:
The Network Manager is our router that sends and receives messages to and from the network. The manager exposes the interfaces that allow:
*Reading a message from the network
*Reading a message from the network
*Sending a message to the network
*Sending a message to the network
*Finalizing the manager
*Finalizing the manager

The read operation is a blocking type operation so we have two options, either Polling and Blocking. We choose Blocking because we don't want to waste CPU time Polling the network for messages, we just want to sleep until messages are available. Hence we create a Thread to read from the Network, let's call it Network Manager Read. To write messages to the network so we can safely code it simply as a method of Network Manager as write is an operation that is non blocking by nature.
The read operation is a blocking type operation so we have two options, either Polling and Blocking. We choose Blocking because we don't want to waste CPU time Polling the network for messages, we just want to sleep until messages are available. Hence we create a Thread to read from the Network, let's call it Network Manager Read.

To write messages to the network so we can safely code it simply as a method of Network Manager as write is an operation that is non blocking by nature.


The Network Manager opens a Socket from which it will receive all the messages from the network, and to where it will write all the messages to the network. Both write and read use the same Socket.
The Network Manager opens a Socket from which it will receive all the messages from the network, and to where it will write all the messages to the network. Both write and read use the same Socket.


To encapsulate all this we create both the Read and Write methods as inner classes of Network Manager. The only difference between them being that Read extends the Thread class while Write is just a standard class.
To encapsulate all this we create both the Read and Write methods as inner classes of Network Manager.

<verbatim>
<pre>
NetworkManager
NetworkManager
{
{
socket
socket
messages
messages
pendingToSendMessages


NetworkManagerRead isa Thread
NetworkManagerRead isa Thread
Line 202: Line 214:
}
}


NetworkManagerWrite
NetworkManagerWrite isa Thread
{
{
get from pendingToSendMessages
build UDP from message
build UDP from message
send socket
send socket
}
}
}
}
</verbatim>
</pre>

As you can see, messages are stored in a list when they are received, hence access to the list is synchronized.
As you can see, messages are stored in a list when they are received, hence access to the list is synchronized.


Now lets get back to the interface as exposed to other objects. The Write method is immediate, just call it with the message to send, making sure that you have correctly filled ~SourceAddress and ClientID, and it will be sent to the Client. It is important to notice that as the transport is based on UDP there are no guarantees that the message is correctly sent. This situation is in the protocol itself. The Read method is blocking, when you call the Read method it either returns a message from the queue or if the queue is empty the thread blocks until one arrives. That is the basic idea of the Network Manager; however, the manager gets a bit more complex as a result of the need to support Server to Client messages that are bigger than one UDP package, the manager just sends the stream of packets once, and doesn't confirm if any of the messages are received. Please refer to UDP Packet Format for more info about it.
Now lets get back to the interface as exposed to other objects. The Write method is immediate, just call it with the message to send, making sure that you have correctly filled SourceAddress and ClientID, and it will be sent to the Client.


!!! Game Manager
Last updated: 2003/09/26

The idea behind the Game Manager is to handle all the "business logic". This Manager decides how to reply to each individual message.

The logic is something like this:
<verbatim>
GameManager
{
NetworkManager read Message

switch(Message type)
{
case ...;
}
}
</verbatim>

So let's define the reply to each message. Before explaining how to process eahc message, let's clarify that the best way of modelling this system is using finite automates, (finite state machine) where, based on the input, we change the state we are currently in and produce an output.
<verbatim>
Process C2S Login ( STATE_BEGIN_LOGIN )
Precondition: The state MUST be NULL

Test if there is room for more players.
if there is no more room
{
reply S2C Login NACK( SERVER_FULL )
state = NULL
}

if check username, password in database is correct
{
create clientid
add PlayerEntry
notify database

reply S2C Login ACK

get characters list of the player
reply S2C CharacterList

state = STATE_LOGIN_COMPLETE
}
else
{
notify database

reply S2C Login NACK( LOGIN_INCORRECT )
state = NULL
}

Postcondition: The state MUST be NULL or STATE_LOGIN_COMPLETE
and a we have created a PlayerEntry for this player with an unique correct clientid.


Process C2S ChooseCharacter ( STATE_LOGIN_COMPLETE )
Precondition: The state MUST be STATE_LOGIN_COMPLETE

if character exists in database
{
add character to Player's PlayerEntry
add character to game
reply S2C Choose Character ACK

state = STATE_GAME_BEGIN
}
else
{
reply S2C Choose Character NACK
state = STATE_LOGIN_COMPLETE
}

Postcondition: The state MUST be STATE_GAME_BEGIN and the PlayerStructure
should be completely filled or if the character choise was wrong the state is STATE_LOGIN_COMPLETE


Process C2S Logout ( STATE_GAME_END )
Precondition: The state can be anything but STATE_LOGIN_BEGIN

if( rpEngine allows player to logout )
{
reply S2C Logout ACK
state = NULL

store character in database
remove character from game
delete PlayerEntry
}
else
{
reply S2C Logout NACK
}

Postcondition: Either the same as the input state or the state currently in


It is important to notice that as the transport is based on UDP there are no guarantees that the message is correctly sent. This situation is in the protocol itself.
Process C2S Perception ACK
Precondition: The state must be STATE_LOGIN_BEGIN


The Read method is blocking, when you call the Read method it either returns a message from the queue or if the queue is empty the thread blocks until one arrives.
notify that the player received the perception.


That is the basic idea of the Network Manager; however, the manager gets a bit more complex as a result of the need to support Server to Client messages that are bigger than one UDP package, the manager just sends the stream of packets once, and doesn't confirm if any of the messages are received. Please refer to UDP Packet Format for more info about it.
Postcondition: The state is STATE_LOGIN_BEGIN and Timestamp field in
PlayerContainer is updated.
</verbatim>


!!!Versioning and port numbering
Last updated: 2004/05/24


=Versioning and port numbering=
A problem arises when we need to have two versions of Marauroa on the same machine. This happens for example when you run a release version and a development version on the same machine.
A problem arises when we need to have two versions of Marauroa on the same machine. This happens for example when you run a release version and a development version on the same machine.


Line 333: Line 247:
gladiators runs at 3214
gladiators runs at 3214
mapacman runs at 3215
mapacman runs at 3215
stendhal runs at 3216


Feel free to follow or disgregard these port rules if you wish. They may not apply to you.
Feel free to follow or disgregard these port rules if you wish. They may not apply to you.
Retrieved from "https://meet.konsthol.eu/w/index.php?title=NetworkDesign"