This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
gamedev:dnp [2022/07/16 16:22] – [Network States] dragonlord | gamedev:dnp [2022/07/18 10:16] – dragonlord | ||
---|---|---|---|
Line 109: | Line 109: | ||
Clients and server can link local network states to the other side. Both client and server can send link requests to the other side. It is up to the application to decide if a link request is accepted or declined. Link requests are handled like [[# | Clients and server can link local network states to the other side. Both client and server can send link requests to the other side. It is up to the application to decide if a link request is accepted or declined. Link requests are handled like [[# | ||
- | The sender assigns a //LinkId// to the state to link. This identifier is then used in the future to reference a linked state. Once assigned the //LinkId// can not be reused until it has been taken down. Multiple clients maintain own links for a local network state. Each connection has potentially a different //LinkId//. Hence //LInkId// are not shared across connections although the state they link is. | + | The sender assigns a //LinkId// to the state to link. This identifier is then used in the future to reference a linked state. Once assigned the //LinkId// can not be reused until it has been taken down. Multiple clients maintain own links for a local network state. Each connection has potentially a different //LinkId//. Hence //LInkId// are not shared across connections although the state they link are. |
In addition to the message delivered to the application the command contains the initial value for all values in the network state. | In addition to the message delivered to the application the command contains the initial value for all values in the network state. | ||
Line 115: | Line 115: | ||
State links can be read write or read only. The sender decided if the receiver is allowed to modify the state or not. Servers usually send read-only states to clients for all entities controlled by the game or other players. The client usually gets a read-write state for his own state he has to modify. The sender has to ignore attempts of clients trying to update states that are read-only to them. | State links can be read write or read only. The sender decided if the receiver is allowed to modify the state or not. Servers usually send read-only states to clients for all entities controlled by the game or other players. The client usually gets a read-write state for his own state he has to modify. The sender has to ignore attempts of clients trying to update states that are read-only to them. | ||
- | The receiver has to send back a [[# | + | The receiver has to send back a [[# |
====== Commands ====== | ====== Commands ====== | ||
Line 144: | Line 144: | ||
| [[# | | [[# | ||
| [[# | | [[# | ||
- | List of supported | + | List of protocols |
* '' | * '' | ||
+ | New protocols can be added in the future. Servers have to ignore unknown protocol values. | ||
</ | </ | ||
Line 161: | Line 162: | ||
* '' | * '' | ||
* '' | * '' | ||
+ | More result codes can be added in the future. All unknown result codes have to be treated is if // | ||
</ | </ | ||
| [[# | | [[# | ||
Line 176: | Line 178: | ||
Send by client or server or server to client. used to send an unreliable message to the other communication partner. Unreliable messages are used for frequently send messages. They are not acknowledged and thus can be possibly lost. Furthermore they can be delivered to the application in any order. Applications have to use unreliable messages only if the loss of information can be compensated, | Send by client or server or server to client. used to send an unreliable message to the other communication partner. Unreliable messages are used for frequently send messages. They are not acknowledged and thus can be possibly lost. Furthermore they can be delivered to the application in any order. Applications have to use unreliable messages only if the loss of information can be compensated, | ||
+ | |||
+ | Messages should be of short length. No explicit fragmenting of message content is done. This is left for the underlying communication channel. If a message is not fully received it has to be considered lost. The exact message size fitting into one communication channel package depends on the communication channel and is often not detectable. As a rule of thumb on IPv4 a package size of 1200 (conservative 540) can be expected to be transmitted in one package. | ||
The command has this format: | The command has this format: | ||
Line 186: | Line 190: | ||
Send by client or server or from server to client. Used to send a reliable message to the other communication partner. Reliable messages are used for infrequent send messages of high importance. They are acknowledged and guaranteed to be received. Furthermore they are guaranteed to be delivered to the application in the order they have been send. Applications have to use reliable messages only if loss of information can not be compensated. | Send by client or server or from server to client. Used to send a reliable message to the other communication partner. Reliable messages are used for infrequent send messages of high importance. They are acknowledged and guaranteed to be received. Furthermore they are guaranteed to be delivered to the application in the order they have been send. Applications have to use reliable messages only if loss of information can not be compensated. | ||
+ | |||
+ | Messages should be of short length. No explicit fragmenting of message content is done. This is left for the underlying communication channel. If a message is not fully received it has to be considered lost. The exact message size fitting into one communication channel package depends on the communication channel and is often not detectable. As a rule of thumb on IPv4 a package size of 1200 (conservative 540) can be expected to be transmitted in one package. | ||
The command has this format: | The command has this format: | ||
Line 197: | Line 203: | ||
Send by client to server or server to client. Used to [[# | Send by client to server or server to client. Used to [[# | ||
+ | |||
+ | Messages should be of short length. No explicit fragmenting of message content is done. This is left for the underlying communication channel. If a message is not fully received it has to be considered lost. The exact message size fitting into one communication channel package depends on the communication channel and is often not detectable. As a rule of thumb on IPv4 a package size of 1200 (conservative 540) can be expected to be transmitted in one package. This size is reduced by the count of value data send along the message. | ||
The command has this format: | The command has this format: | ||
Line 260: | Line 268: | ||
Send by client to server or server to client. Used to update a remote state. Client or server is only allowed to send a state update if it has a read-write state. This is the case if the client or server linked the state to other sides or it received a state with read-write capability. | Send by client to server or server to client. Used to update a remote state. Client or server is only allowed to send a state update if it has a read-write state. This is the case if the client or server linked the state to other sides or it received a state with read-write capability. | ||
- | The command contains one or more values to update which do not have to be of the same state. The sender is not required to update all values with one command send. The sender decides how many values it includes in the command and when it updates the values. In general the sender has to update state changes as fast as possible. The data type range and precision information assigned to values has to be used to send updates only if necessary. For example a floating point value with 0.1 precision should only send an update if the value set by the application deviates more than 0.1 from the last known value. The application sets the precision according to needs. Optionally the sender can update state values if they have recently changed but not more than their precision requires. | + | The command contains one or more values to update which do not have to be of the same state. The sender is not required to update all values with one command send. The sender decides how many values it includes in the command and when it updates the values. In general the sender has to update state changes as fast as possible. The data type range and precision information assigned to values has to be used to send updates only if necessary. For example a floating point value with 0.1 precision should only send an update if the value set by the application deviates more than 0.1 from the last known value. The application sets the precision according to needs. Optionally the sender can update state values if they have recently changed but not more than their precision requires. This can be used as a kind of " |
If the receives values change enough (according to the same rules as sending them) the application has to be send notification for each changed value. | If the receives values change enough (according to the same rules as sending them) the application has to be send notification for each changed value. |