NetworkDesign: Difference between revisions
Jump to navigation
Jump to search
Content deleted Content added
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
= Basic idea behind Networking = |
|||
<?plugin CreateToc with_toclink||=1 ?> |
|||
The idea behind arianne network protocol is to use a single stream of UDP packets to comunicate server and clients, to allow the different kind of actions we create different types of messages that are then interpreted at the opposite peer. |
|||
| ⚫ | |||
Last updated: 2003/08/26 |
|||
| ⚫ | |||
The Network design is based on Messages being transmitted using UDP Packets. There are two types of streams, one is Server to Client and another one that is Client to Server. |
The Network design is based on Messages being transmitted using UDP Packets. There are two types of streams, one is Server to Client and another one that is Client to Server. |
||
===UDP Client to Server communication stream=== |
|||
Each message is self contained in a SINGLE UDP Packet. There is no mechanism for recovery of lost or repeated messages. |
Each message is self contained in a SINGLE UDP Packet. There is no mechanism for recovery of lost or repeated messages. |
||
| Line 15: | Line 14: | ||
*Rest of Message ( up to 1494 bytes ) |
*Rest of Message ( up to 1494 bytes ) |
||
===UDP Server to Client communication stream=== |
|||
Each message is contained in one or more UDP Packets, and the UDP Packet format is as follows: |
Each message is contained in one or more UDP Packets, and the UDP Packet format is as follows: <br> |
||
1st UDP Packet is composed of: |
|||
*Total number of packets (1 byte) |
*Total number of packets (1 byte) |
||
*Position of this message (1 byte) |
*Position of this message (1 byte) |
||
| Line 24: | Line 24: | ||
*Client ID (4 bytes) |
*Client ID (4 bytes) |
||
*Rest of Message (up to 1491 bytes) |
*Rest of Message (up to 1491 bytes) |
||
The following UDP Packets are composed of: |
The following UDP Packets are composed of: |
||
*Total number of packets (1 byte) |
*Total number of packets (1 byte) |
||
| Line 29: | Line 30: | ||
*Signature of the message (1 byte) |
*Signature of the message (1 byte) |
||
*Rest of Message (up to 1497 bytes) |
*Rest of Message (up to 1497 bytes) |
||
The idea is to send the serialized message inside several UDP Packets and then rebuild the full message on the Client. There is no kind of error recovery, or retransmission. |
The idea is to send the serialized message inside several UDP Packets and then rebuild the full message on the Client. There is no kind of error recovery, or retransmission. |
||
Messages are sent from the Server by simply serializing them. So the message itself contains the protocol version, the type of message and the Client id. |
Messages are sent from the Server by simply serializing them. So the message itself contains the protocol version, the type of message and the Client id. |
||
Receiving the message is a bit more complex. First we need to determine that we are running a compatible version of the protocol. Once we have agreed that the protocol is compatible we read the type of message and we ask a |
Receiving the message is a bit more complex. First we need to determine that we are running a compatible version of the protocol. Once we have agreed that the protocol is compatible we read the type of message and we ask a Message Factory ( "Java Design Patterns" ) to build an object of that type with the coresponding data. Once the message is build we simply store it in a queue of incoming messages waiting to be processed. |
||
<verbatim> |
|||
Thread Read |
|||
{ |
|||
receive UDP |
|||
if(Packet[0]==PROTOCOL_VERSION) |
|||
{ |
|||
push MessageFactory.getMessage(Packet[1]) |
|||
} |
|||
} |
|||
Thread Write |
|||
{ |
|||
send UDP |
|||
} |
|||
</verbatim> |
|||
| ⚫ | |||
Last updated: 2003/09/11 |
|||
| ⚫ | |||
To communicate, the Client and Server of Marauroa use a stream of UDP packets. The message system belongs to the marauroa.net package, so refer to code. |
To communicate, the Client and Server of Marauroa use a stream of UDP packets. The message system belongs to the marauroa.common.net package, so refer to code. |
||
We have Client to Server, aka C2S, and Server to Client, aka S2C, messages. |
We have Client to Server, aka C2S, and Server to Client, aka S2C, messages. <br> |
||
Most messages have two versions of themselves: the C2S and S2C versions. |
|||
Communication Model |
Communication Model |
||
| Line 83: | Line 67: | ||
Send Perception ACK Send Perception |
Send Perception ACK Send Perception |
||
--on |
--on RPManager request: |
||
Send |
Send TransferREQ |
||
Send TranferACK |
|||
Send Transfer |
|||
--onEvent: |
--onEvent: |
||
| Line 98: | Line 84: | ||
Let's discuss in detail each message type. |
Let's discuss in detail each message type. |
||
==Message C2S Login== |
|||
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. |
||